LinkedIn Mobile
Lessons from Building

Culture
Product & Design
Development Background
Our Choices
Server
Client

Cult of Simple
• Fast
– App Launch
– Screen to Screen Switch
• Easy
– Tap Count
• Reliable
– Don’t Crash
– Repeatable

Product & Design
It impacts engineering

Websites vs. Applications
Content Focus Flow & Action Focus
Long Form Layout Lists/Details
Responsive Design
Good for websites; Not for applications

Interaction vs. Visual
• Design a house floor plan
• Focus on Rooms and Hallways
• Stay away from Paint, Furniture Carpet
• Has & Does for each screen
• Black & White then Color

Adjust App Platforms
• On Screen vs. Hardware Back
• Up vs. Back / Stacks vs. Pages
• Pull to Refresh vs. Button Refresh
• Settings Room Location
• Visual Design

Development Background
Approach to Engineering

HTML5 vs Native
• What is the skillset of the team?
• What is your front door?
• Which platforms are you targeting?
• Phone Gap vs Titanium vs XXX

Libs vs. Frameworks
Frameworks call App call libraries
your app
(Few) (Lots)

Process vs Evented
Systems

Process Systems
Single process/thread per request
Block while waiting for I/O to complete
Use Process/Thread Pools

Evented Systems
Single Process for large number of requests
Non Blocking for I/O
Use 1 Process per Core on system for scale

Evented For Mobile
Process Systems great for high compute
Evented Systems great for I/O bound
With mobile client rendering,
evented systems best for front end

Our Choices

Server

Mobile Server
• Scaling Node
• Node Modules
• Logging vs Tracking vs Metrics
• File Structure / Code Size
• Client / Server Line Format
• Server / Server Line Format
• Latency vs Bandwidth
• Gotchas

Scaling
• Load Balancer talking to each node instance
running on separate cores
• In Node .8, finally have master/child file
handle sharing based evented model
• 150 qps per core per instance
• 60 MB of RAM for an instance

Node Modules
• Step to Async
• Express/Connect -- Framework
• Vows to Mocha
• Request
• Underscore

Logging/Monitoring/Tracking
• Logging used for sending lots of text information
– useful for debugging
• Monitoring is for sending counters for realtime
monitoring: Product and System
– Typical: Query Rate, Response Code, Time for
request, Page Views, Actions
– Cube from Square
• Tracking is for product metric queries
– Get into a database for queries
– Needed for doing Uniqing and Pathing queries

File Structure / Code Size
• Follow simple Rails/Django dir
– Controllers, Helpers, Formatters, Templates
– No Views, No Models
• Code Size ~ 10K

Client / Server Line Level
• Single Request per screen
• JSON is template based
• Updateable on Server
• Don’t add:
– Links
– Styles
– Positioning
• Node is part of the client
NOT the server

Server / Server Line Level Format
• Stream Data
– Metrics, Logging, Events, etc
– Kafka, Thrift, Avro, Protocol Buffers etc.
• Request/Response Data
– HTTP/JSON
– REST Endpoints for actual data models
– Not much faster for performance

Latency vs. Bandwidth
• Latency is the issue with mobile not
bandwidth
• Establish and keep the socket open for ping
• Use a ping and pull model not a true push
• Easier to scale ping/pull model

Node Gotchas
• Exception Handling
• Don’t listen on startup till you are connected
to down stream services
• Okay to die and respawn
• httpClient.agent = false
• Turn on console in production
• NO BLOCKING!

Client
Native for Infinite Scroll
Native for Window Manger
HTML5 for everything else

iOS / Android Native

Native Gotchas
Web to Native Messaging
Cache/Image Management
Tools / Test

Web to Native Messaging
• iFrame with URL for Ping
• Native Pulls from Queue
• Web-Sockets suck
• REST for Native Services

Cache/Image Management
• Store all data in url/result hash
• Render data from Hash
• Render again from server response
• Image src should be set to small image when
off screen

Tools/Test
• iWebInspector / Weinre
• Charles Proxy for req debugging
• Pain when OS upgrade
• Selenium with Safari Simulator (Web Parts)
• Instruments UIAutomation / Robotium (Native)
• Layout Test: DumpRender + ImageDiff (5%)
• Vcr.js – Fixture Creater
• Android Emulator Super Slow to have to do on
build machine with catchup

Mobile Web

Screen vs Page
• App is multiple Screens in one page
• Page is a browser Page and has an implication
of JS Load/Parse time
• Screen to Screen move is div show/hide

Backbone.js
• Controls Routing from Screen to Screen
• Controls Screen lifecycle (load, show, hide)
• Controls View Updating based on Model
Change
• Has Model construct for Validation
• BaseRouter to Backbone
– Transitions, screen life cycle
• M V C links in Backbone lead to mem leaks

Libraries
• Zepto – Manipulate the DOM
• iScroll – Inertial Scrolling on iOS
– Does not work on Android
– Pull to Refresh
• Underscore – Collection helpers and binding
constructs, templating

Build / Packaging
• Closure
– Minify, Comment Removal, Template Compilation
• SASS
– Variables, Functions, Selector Inheritance
• Bundle (set of screens)
– Local, Template, Controllers/Views
• Build independently and resuable

Startup
• Initial
– Index.html
– List of bundle files
– Store all in Local Storage
– Backbone starts home bundle
• Upgrade
– Index.html
– MD5 has for each file
– Compare/Download Diff
– Store in Local Storage

Tools / Gotchas
• Chrome Memory Profiler
– https://developers.google.com/chrome-
developer-tools/docs/heap-profiling
• Memory Leak Tracking
– http://gent.ilcore.com/2011/08/finding-memory-
leaks.html
• Hardware Acceleration for DIV render only on
screen DIV’s
• Double Render from Cache