Designing an API for Mobile - SocialRadar

  • View
    385

  • Download
    1

  • Category

    Mobile

Preview:

DESCRIPTION

Designing an API for mobile - Lessons we've learned at SocialRadar. Given at API Craft DMV meetup in April 2014.

Citation preview

Victor Quinn @victorquinn

Lead Node.js Engineer

Designing an API for MobileAPI Craft DMV Meetup, April 28 2014

Download

Gives you real-time information on the people around you

!It’s free!!

!This will be pretty fast-paced

More About SocialRadar

Special considerations for a Mobile API

• Speed really matters • Battery usage - minimize

• Maximizing network utilization • Response size matters • Minimize number of requests

• Stateless

Speed: Problems• Only one thing on screen at a time, perception change

• On desktop other things can distract • Best Case: ~400ms latency for round trip on cell network

• We tested at SocialRadar using a basic ping no-op endpoint

• Verizon LTE, iPhone 5S • Device doesn’t maintain active connection • Average case much worse, ~1000ms round trip

Ideal round tripiPhone 5S on Verizon LTE

User's Phone API

200ms

200ms

200ms

Total round trip time 800ms

200ms

bit of hand waving, I’m not a network expert

Likely round tripiPhone 4S on Verizon 3G

User's Phone API

500ms

500ms

200ms

Total round trip time 1600ms

400ms

Speed: Solutions• Cache anything humanly possible • Respond as quickly as possible, deferring

anything that doesn’t need to be done immediately • Queue most things • Make sure your API can handle high concurrency

(we settled on Node.js to accomplish this, WhatsApp uses Erlang)

Minimize battery usage

!• Brief note about cell battery and network

usage (more) • Response size matters • Minimize number of requests

Maximize network utilization

Response Size: Problems• At SocialRadar, we tested responses of different sizes • Optimal was largest response that would fit into a

single TCP packet on the cell network. • Around 128KB. Differs based on client device and

network • Any longer would jump response time significantly

Response Size: Solutions• Paging sizes — largest

that fit within TCP packet window • Contrast with

Desktop, paging more dependent on server response time and UI

User's Phone API

200ms

200ms

200ms

Total round trip time 800ms

200ms

Page size of 20 users

To retrieve 100 users, ~4s

Paging Size: 20 (Ideal)

Paging Size: 50 (Ideal)

User's Phone API

200ms

200ms

500ms

Total round trip time 1100ms

200ms

Page size of 50 users

To retrieve 100 users, ~2.2s

Paging Size: 20 (Likely)

User's Phone API

500ms

500ms

200ms

Total round trip time 1600ms

400ms

To retrieve 100 users, ~8s

Paging Size: 50 (Likely)

User's Phone API

500ms

500ms

500ms

Total round trip time 1900ms

400ms

To retrieve 100 users, ~3.8s

Number of Requests: Problems• Traditionally parallelized, not (well) on mobile • Battery life is of great concern and every network

request eats into that • Spinning up the cell modem, making request,

waiting for it drains the battery • So if you make 5 requests instead of 1, draining

battery, leaving user waiting

Number of Requests: Solutions

• Paging size as mentioned above, try to maximize response that will fit in a packet to minimize the number of requests • So one request with 20KB much better than 5

with 4KB each • Batch multiple requests into a single one

Batch Request Library

• Finding no great existing batch request library for Node.js, we rolled our own open source library

• http://batch-request.socialradar.com • Allows you to send a single request that represents

multiple • No need to compromise on RESTful principles and

move to a SOA • Handles complex dependencies

Batch Request Library (2)1. npm install batch-request 2. Add one line of code to your API:

app.post('/batch', batch.validate, batch);!3. Send batch request as single POST:

{ "myRequest1": { "method": "GET", "uri": "http://api.mysite.com/users/1/first_name" }, "myRequest2": { "method": "GET", "uri": "http://api.mysite.com/users/1/email" } }

Batch Request Library (3)4. Receive single response:

{ "myRequest1": { “statusCode": 200, “body": “Victor”, “headers”: {…} }, "myRequest2": { “statusCode": 200, “body": “victor@socialradar.com”, “headers”: {…} } }

When you pull to refresh, Batch Request to:

• Update user location with

latest GPS reading • Retrieve current City/State • Retrieve most recent stat

numbers • Get some user lists to

cache them

Stateless• Cell networks are spotty

• For performance, want load balance among multiple servers

• Solution: Assign access token to device rather than relying on sessions for user access

• We have an access token which is an encrypted string containing user_id and some other stuff

Victor Quinn @victorquinn

Lead Node.js Engineer !

Download our App

Questions?

Recommended