Application Program Interfaces (API’s) represent an effective way to build and manage mobile services. By using API’s -- a set of routines, protocols and tools for building software applications -- application developers no longer have to buy technology software or hardware. Instead, they can simply plug into a growing open ecosystem of API-driven services. It is simple to integrate, and saves time and money for new developers.
There are countless mobile API-based services. From authentication, ads and payment API’s to price comparison and reporting API based services. The availability of these API’s made mobile app development much simpler, but this simplicity comes with a price.
Unlike images, game assets, videos and other type of static content, API’s are dynamic in nature and their content cannot be cached at the edge of the internet to increase download speed. Often times the result of an API call is customized per user profile, its location and the activity he/she is trying to accomplish. A user searching for a Mexican restaurant in downtown San Francisco will get a unique (non cacheable) search result.
There are three main challenges with existing API configurations that directly impact any mobile app performance:
- Response Time – Since API responses are usually personalized, its content cannot be cached by the CDN. Some of the responses could be sizeable and include dozens of images that will have to be downloaded on a slow mobile connection. This impacts the API response time and eventually the mobile app.
- Reliability – Mobile networks are less reliable than wired networks with Packet Loss and error rates that are 10-20 times higher. This affects not only the app API response time but most importantly its failure rates. Mobile developers have to factor into their code fail conditions and a proper way to handle each one of them, which can complicate things.
- Server Load – There are two sources for high server load: (A) Failed transactions due to network error will usually follow by API call retry, keeping the server busier than it should be; and (B) API calls over slow connections means that the server has to keep connections open longer, consuming more resources than needed.
How could mobile developers mitigate the risk when using APIs?
While caching is not possible, one could accelerate an API call using a few techniques:
- Protocol Optimization. By avoiding slow starts, backoffs and other TCP hiccups, downloading a sizeable API response could become faster. Traditional CDNs offer such an optimization in the middle mile for a premium price.
- Routing Optimization. Speeding up access to the origin server API can be achieved through better routing of the request/response in the first and middle miles. Traditional CDNs can offer this for a premium price.
- Persistent Connections. To avoid the “TCP handshake” overhead one could keep the connection open/warm and save a few round trips for each new request. This technique should be used carefully since overusing it will once again increase server load.
Unfortunately, since all the above techniques take place in a wired network (as opposed to the wireless link) the performance impact is marginally low while the cost (to various vendors) is not.
Most importantly, none of these techniques can be technically integrated with 3rd party APIs, unless the vendor operating the service is cooperating.
How can PacketZoom help?
- PacketZoom Mobile Expresslane operates on the last mobile mile which contributes to 70% of the latency and over 90% of the network errors.
- PacketZoom avoids TCP slow start since it leverages big data of network profiles.
- PacketZoom keeps the connection alive even after the mobile client loses its IP address. This saves the developer the need to catch the exception, analyze it and re-call the API.
- When a disconnect takes place during an API call, PacketZoom resumes the request. Instead of making the backend server do the work again, you can just pick up where it left off.
- PacketZoom saves developers the need to retry an API call and reduces server load (i.e fewer failed API calls).
- Per Apple guidance most APIs are now secured (using TLS) which adds two extra round trips to establish a connection. Since PacketZoom proxy makes all the requests from a single source it uses connection pool more efficiently while avoiding performance overhead.
- Some API responses (such as “deal of the day”) could be cached for a limited time so app developers add an extra geo-caching layer to support this. PacketZoom already provides this functionality and all app developers should do is to configure the caching rules in the response according to the standard HTTP specs.
Field Test Result
The data below was collected from devices installed in dozens of cars in Asia for a few days. Each device was executing hundreds of API calls per hour with two different protocols (TCP and PacketZoom).
We measured two KPIs:
- API response time
- Error rate
As you can see when using the PacketZoom protocol the API was almost twice as fast to respond and three times more reliable (i.e. over 75% fewer errors)