Mobile apps & Server
APIs, the weak link?
Summary
1. Why going for mobile?
Summary
1. Why going for mobile?
2. The Viadeo mobile app
Summary
1. Why going for mobile?
2. The Viadeo mobile app
3. Are mobile applications only a client?
Summary
1. Why going for mobile?
2. The Viadeo mobile app
3. Are mobile applications only a client?
4. Our architecture
Summary
1. Why going for mobile?
2. The Viadeo mobile app
3. Are mobile applications only a client?
4. Our architecture
5. Issues to face
Internet is changing
From here … to there !
GLOBAL MOBILE TRAFFIC GROWING RAPIDLY TO REACH
10% OF INTERNET TRAFFIC
SMARTPHONE USER ADOPTION HAS
HUGE UPSIDE POTENTIAL
GOOD NEWS:
MONETIZATION ALSO GROWING RAPIDLY
MOBILE IN VIADEO
Viadeo mobile
Improve user
experience with mobile
Tianji mobile
Improve user
experience with mobile
Launch new apps to boost traffic
Mobile labs
NEW: VIADEO MOBILE BUSINESS UNIT
→ Go Fast !
→ Autonomous - not independant ;-)
→ Lean Startup mode
THE VIADEO APPLICATION
The video
THE USER WANTS…
1. No crash!
THE USER WANTS…
1. No crash!
2. A fast application
THE USER WANTS…
1. No crash!
2. A fast application
3. Small traffic and save battery life
THE USER WANTS…
1. No crash!
2. A fast application
3. Small traffic and save battery life
4. Security
USER WANTS A SUPER APP
ONLY FOCUS ON CLIENT
SIDE DEVELOPMENT?
FOCUS ON CLIENT SIDE
1. Native vs HTML5
2. Design and ergonomy
3. Responsive interface
4. Follow guidelines
BUT…
Limited capabilities of the devices
BUT…
Limited capabilities of the devices
GREAT
BUT…
Limited capabilities of the devices
GREAT
BUT
BUT…
Limited capabilities of the devices
GREAT
BUT
NOT SO GREAT
FEATURE PHONES?
ARE THEY IMPORTANT?
BUT…
Slow and unreliable network
1. 4G
BUT…
Slow and unreliable network
1. 4G
2. 3G
BUT…
Slow and unreliable network
1. 4G
2. 3G
3. EDGE
BUT…
Slow and unreliable network
1. 4G
2. 3G
3. EDGE
4. GPRS
FOCUS ON THE SERVER SIDE
A GREAT CLIENT
APPLICATION BEGINS ON
SERVER SIDE
TO BE CONSIDERED
1. API sends a lot of data (XML/JSON) ->
my feed of news can be 60kb
TO BE CONSIDERED
1. API sends a lot of data (XML/JSON) ->
my feed of news can be 60kb
2. Mobile applications need to reduce
number of requests to get data
TO BE CONSIDERED
1. API sends a lot of data (XML/JSON) ->
my feed of news can be 60kb
2. Mobile applications need to reduce
number of requests to get data
3. API needs to serve millions of mobile
devices
WHAT CAN WE DO?
1. Transform, filter and compress data
WHAT CAN WE DO?
1. Transform, filter and compress data
2. Aggregate calls on server side
WHAT CAN WE DO?
1. Transform, filter and compress data
2. Aggregate calls on server side
3. Scalable architecture
VIADEO MOBILE ARCHITECTURE
VIADEO API MEMCACHE,
DATABASE, …
VIADEO MOBILE ARCHITECTURE
MIDDLE END
or
MOBILE API
(2 servers)
VIADEO API
(6 servers) MEMCACHE,
DATABASE, …
NodeJS
1. Small memory footprint
NodeJS
1. Small memory footprint
2. Event driven architecture (single event
loop vs multiple blocking threads)
NodeJS
NodeJS
1. Small memory footprint
2. Event driven architecture (single event
loop vs multiple blocking threads)
3. Great to work with JSON
Middlend usage example
SMARTNEWS
Middlend usage example
SMARTNEWS
News proposed targeting your
areas of interest.
More you use Viadeo, more the
smartnews will be accurate
Middlend usage example
SMARTNEWS
News proposed targeting your
areas of interest.
More you use Viadeo, more the
smartnews will be accurate
The JSON data in the next slide is what
the API sends for a single news
Middlend usage example
Middlend usage example
EVERYTHING IS OK?
DOWNLOAD OF THE CONTACTS LIST
After the login, the application starts to
download the complete list of your Viadeo
contacts
EVERYTHING IS OK?
DOWNLOAD OF THE CONTACTS LIST
After the login, the application starts to
download the complete list of your Viadeo
contacts
EVERYTHING IS OK?
DOWNLOAD OF THE CONTACTS LIST
After the login, the application starts to
download the complete list of your Viadeo
contacts
Some users have contacts list with thousands of contacts
Problem
Middleend makes parallel calls to the API
to get the contacts list and send back to
the user:
Parallel calls of 200 contacts
User with 5000 contacts = 25 calls x 200
contacts
Test
Test of the preprod platform
with many parallel calls gives
you good results
Problem
Launch of new iPhone application
Problem
Launch of new iPhone application
Big traffic increase and many calls to
download the contact list
Problem
Launch of new iPhone application
Big traffic increase and many calls to
download the contact list
Access time to memcache and database
increases
Problem
0
2000
4000
6000
8000
10000
12000
14000
16000
10:30 10:31 10:32 10:33 10:34 10:35 10:36 10:37 10:38 10:39 10:40 10:41 10:42 10:43 10:44
Avg. Response time (ms)
Problem
RESULT:
Access to memcache and database is
very slow or impossible
The application doesn’t work
What’s going on?
• Put useful information about performances
in your log
• Use good realtime analysis tools
• AppDynamics
• Splunk
• Use data mining tools
• Datameer
• Setup alert system to get warned about
performance issues
Source of the problems
Your production environment is different
from the preprod environment:
1. Not only mobile traffic on the API
(widgets)
2. Webapp access to the backend resource
3. Presence of daemon and batches that
access the memcache or the database
Solutions
1. Optimize the way middleend downloads
the contact list to decrease charge on API
2. Reduce access to database and
memcache (code improvements)
3. Optimize calls to the API (reduce
numbers of calls or data size)
4. Reduce the impact of other systems
especially in traffic peak time
Other thoughts around mobile app and API
ERROR CODES
Often API are designed to answer only with
HTTP code to notify errors
Enhance your response with data in the JSON
response to allow client to really recognize the
error and show an appropriate message to the
user.
NOT ONLY 400 (BAD REQUEST)
Other thoughts around mobile app and API
1. Additional error code in the Json response
and recognize it on application side
2. Add a specific message in the Json
response that the application can show to
the user (manage multiple languages)
Other thoughts around mobile app and API
VERSIONING
{
"id": "jhAzouiEhDiDoaligeyAAslvAA",
"picture": "http://myphoto.com/images/photos/3749237498/"
}
WHAT IF I NEED TO CHANGE TO:
{
"id": "jhAzouiEhDiDoaligeyAAslvAA",
"picture_link": "http://myphoto.com/images/photos/3749237498/"
}
Other thoughts around mobile app and API
VERSIONING
• Impossible to update all the mobile
applications at the same time to support the
new structure
• Server must be able to respond both to old
and new versions requests
Other thoughts around mobile app and API
VERSIONING
• Send both fields?
{
"id": "jhAzouiEhDiDoaligeyAAslvAA",
"picture":
"http://myphoto.com/images/photos/3749237498/"
"picture_link":
"http://myphoto.com/images/photos/3749237498/"
}
Other thoughts around mobile app and API
VERSIONING • Use the Http «Accept» header: server load the response model
and serialize the response according to the version 1.0
Accept: /myapplication1.0
{
"id": "jhAzouiEhDiDoaligeyAAslvAA",
"picture": "http://myphoto.com/images/photos/3749237498/"
}
Accept: /myapplication2.0
{
"id": "jhAzouiEhDiDoaligeyAAslvAA",
"picture_link": "http://myphoto.com/images/photos/3749237498/"
}
Other thoughts around mobile app and API
KEEP CLIENT AUTHENTICATED
• First connection: authenticate your client
accessing the Database
• Store the information in session and sends
back the session-id to the client
• Mobile app sends the session-id in the next
requests
• Server can check the existence of a session
without accessing the database
MOBILE TEAM IS HIRING
PASSIONATE ABOUT
MOBILE?
SEND US YOUR CV:
© Viadeo 2010
Thanks a lot for your attention!
Q & A
Emanuele Pecorari Mobile Architect
http://fr.viadeo.com/en/profile/emanuele.pecorari