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

Long Form Layout

Flow & Action Focus

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 your app

(Few)

App call libraries(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

• 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

Client / Server Line Level

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