The document discusses the challenges and strategies involved in developing mobile applications and server APIs for Viadeo, emphasizing the importance of optimizing server capabilities for mobile traffic and user experience. It outlines the architecture used, issues faced, and solutions implemented to enhance application performance, including data processing and error handling. Additionally, the document addresses client-server communication and the need for versioning and authentication in API design.

1. Mobile apps & Server
APIs, the weak link?

2. Summary
1. Why going for mobile?

3. Summary
1. Why going for mobile?
2. The Viadeo mobile app

4. Summary
1. Why going for mobile?
2. The Viadeo mobile app
3. Are mobile applications only a client?

5. Summary
1. Why going for mobile?
2. The Viadeo mobile app
3. Are mobile applications only a client?
4. Our architecture

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

7. Internet is changing
From here … to there !

8. GLOBAL MOBILE TRAFFIC GROWING RAPIDLY TO REACH
10% OF INTERNET TRAFFIC

9. SMARTPHONE USER ADOPTION HAS
HUGE UPSIDE POTENTIAL

10. GOOD NEWS:
MONETIZATION ALSO GROWING RAPIDLY

11. MOBILE IN VIADEO
Viadeo mobile Tianji mobile
Improve user Improve user
experience with mobile experience with mobile
Mobile labs
Launch new apps to boost traffic

12. NEW: VIADEO MOBILE BUSINESS UNIT
→ Go Fast !
→ Autonomous - not independant ;-)
→ Lean Startup mode

13. THE VIADEO APPLICATION
The video

14. THE USER WANTS…
1. No crash!

15. THE USER WANTS…
1. No crash!
2. A fast application

16. THE USER WANTS…
1. No crash!
2. A fast application
3. Small traffic and save battery life

17. THE USER WANTS…
1. No crash!
2. A fast application
3. Small traffic and save battery life
4. Security

18. USER WANTS A SUPER APP
ONLY FOCUS ON CLIENT
SIDE DEVELOPMENT?

19. FOCUS ON CLIENT SIDE
1. Native vs HTML5
2. Design and ergonomy
3. Responsive interface
4. Follow guidelines

20. BUT…
Limited capabilities of the devices

21. BUT…
Limited capabilities of the devices
GREAT

22. BUT…
Limited capabilities of the devices
BUT
GREAT

23. BUT…
Limited capabilities of the devices
BUT
GREAT NOT SO GREAT

24. FEATURE PHONES?

25. ARE THEY IMPORTANT?

26. BUT…
Slow and unreliable network
1. 4G

27. BUT…
Slow and unreliable network
1. 4G
2. 3G

28. BUT…
Slow and unreliable network
1. 4G
2. 3G
3. EDGE

29. BUT…
Slow and unreliable network
1. 4G
2. 3G
3. EDGE
4. GPRS

30. FOCUS ON THE SERVER SIDE
A GREAT CLIENT
APPLICATION BEGINS ON
SERVER SIDE

31. TO BE CONSIDERED
1. API sends a lot of data (XML/JSON) ->
my feed of news can be 60kb

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

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

34. WHAT CAN WE DO?
1. Transform, filter and compress data

35. WHAT CAN WE DO?
1. Transform, filter and compress data
2. Aggregate calls on server side

36. WHAT CAN WE DO?
1. Transform, filter and compress data
2. Aggregate calls on server side
3. Scalable architecture

37. VIADEO MOBILE ARCHITECTURE
VIADEO API
MEMCACHE,
DATABASE, …

38. VIADEO MOBILE ARCHITECTURE
MIDDLE END
or VIADEO API
MOBILE API MEMCACHE,
(6 servers)
(2 servers) DATABASE, …

39. NodeJS
1. Small memory footprint

40. NodeJS
1. Small memory footprint
2. Event driven architecture (single event
loop vs multiple blocking threads)

41. NodeJS

42. NodeJS
1. Small memory footprint
2. Event driven architecture (single event
loop vs multiple blocking threads)
3. Great to work with JSON

43. Middlend usage example
SMARTNEWS

44. Middlend usage example
SMARTNEWS
News proposed targeting your
areas of interest.
More you use Viadeo, more the
smartnews will be accurate

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

46. Middlend usage example

47. Middlend usage example

48. EVERYTHING IS OK?
DOWNLOAD OF THE CONTACTS LIST
After the login, the application starts to
download the complete list of your Viadeo
contacts

49. EVERYTHING IS OK?
DOWNLOAD OF THE CONTACTS LIST
After the login, the application starts to
download the complete list of your Viadeo
contacts

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

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

52. Test
Test of the preprod platform
with many parallel calls gives
you good results

53. Problem
Launch of new iPhone application

54. Problem
Launch of new iPhone application
Big traffic increase and many calls to
download the contact list

55. Problem
Launch of new iPhone application
Big traffic increase and many calls to
download the contact list
Access time to memcache and database
increases

56. Problem
Avg. Response time (ms)
16000
14000
12000
10000
8000
6000
4000
2000
0
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

57. Problem
RESULT:
Access to memcache and database is
very slow or impossible
The application doesn’t work

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

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

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

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

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

63. 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/"
}

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

65. 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/"
}

66. 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/"
}

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

68. MOBILE TEAM IS HIRING
PASSIONATE ABOUT
MOBILE?
SEND US YOUR CV:
hrit@viadeo.com

69. Thanks a lot for your attention!
Q&A
Emanuele Pecorari
Mobile Architect
epecorari@viadeoteam.com
http://fr.viadeo.com/en/profile/emanuele.pecorari
© Viadeo 2010