Mobile apps & Server Apis, the weak link? par Emanuele Pecorari

Post on 06-Dec-2014

1.822 views 1 download

Tags:

description

Mobile apps & Server Apis, the weak link ? Open discussion on the mobile apps, and server apis/webservices based on video's return on experience after the recent relaunch of its mobile apps. http://fr.viadeo.com/en/profile/emanuele.pecorari

Transcript of Mobile apps & Server Apis, the weak link? par Emanuele Pecorari

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:

hrit@viadeo.com

© Viadeo 2010

Thanks a lot for your attention!

Q & A

Emanuele Pecorari Mobile Architect

epecorari@viadeoteam.com

http://fr.viadeo.com/en/profile/emanuele.pecorari