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

1. Victor Quinn
@victorquinn
Lead Node.js Engineer
Designing an API for Mobile
API Craft DMV Meetup, April 28 2014

2. Download
Gives you real-time information
on the people around you
!
It’s free!!
!
This will be pretty fast-paced
More About SocialRadar

3. Special considerations for a
Mobile API
• Speed really matters
• Battery usage - minimize
• Maximizing network utilization
• Response size matters
• Minimize number of requests
• Stateless

4. 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

5. Ideal round trip
iPhone 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

6. Likely round trip
iPhone 4S on Verizon 3G
User's Phone API
500ms
500ms
200ms
Total round trip time 1600ms
400ms

7. 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)

8. Minimize battery usage
!
• Brief note about cell battery and network
usage (more)
• Response size matters
• Minimize number of requests
Maximize network utilization

9. 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

10. Response Size: Solutions
• Paging sizes — largest
that fit within TCP packet
window
• Contrast with
Desktop, paging more
dependent on server
response time and UI

11. 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)

12. 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

13. Paging Size: 20 (Likely)
User's Phone API
500ms
500ms
200ms
Total round trip time 1600ms
400ms
To retrieve 100 users, ~8s

14. Paging Size: 50 (Likely)
User's Phone API
500ms
500ms
500ms
Total round trip time 1900ms
400ms
To retrieve 100 users, ~3.8s

15. 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

16. 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

17. 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

18. 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"
}
}

19. Batch Request Library (3)
4. Receive single response:
{
"myRequest1": {
“statusCode": 200,
“body": “Victor”,
“headers”: {…}
},
"myRequest2": {
“statusCode": 200,
“body": “victor@socialradar.com”,
“headers”: {…}
}
}

20. 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

21. 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

22. Victor Quinn
@victorquinn
Lead Node.js Engineer
!
Download our App
Questions?