share

ENGINEERING

4min read

Optimizing API against latency

Designing an API is an incredibly important moment for a project’s future. Every change made in the future will be accompanied by having to support multiple versions of an API, modifying docs, server-side code and the client. Because of this laundry list of changes to keep track of, we try to solve as many design problems as possible up front.
There are several different areas, that make a huge impact. The one we target in this post is latency.

Latency is a time interval between the stimulation and response (…). Wikipedia, Latency (engineering)

What is latency when it comes to mobile devices? Mobile networks are still far from what we would call high performance. There is huge overhead required when you make even a single request from your mobile app. A quick list of the steps needed:

  • RRC negotiation
  • DNS lookup
  • TCP handshake
  • TLS handshake
  • HTTP request

Beyond just this one complicated path, we need to keep in mind some potential problems:

  • weak signal
  • lost signal
  • client is moving and changing base stations
  • routing gets mixed up - source
  • different pings originating from the same location(home/office) - source

You end up with a latency of 100ms-300ms for 3G networks and up to 1000ms for 2G. Since 2G is becoming obsolete and 4G is just around the corner for our users (check this thread), let’s take a look at a forecast from Cisco Systems, Inc. (source).

CISCO mobile connection speed forecast

What this shows is that 4G shouldn’t be treated as the representative network connection of our users. Of course we should be able to target our application well and if it’s an app for geeks, let’s say a StackOverflow client, the subsequent network connection speed will be drastically higher than when compared to a general purpose app like a news reader.

We can deal with latency by trying to optimize DNS lookup counts, shorten the request route, and many many more. We could even go so far as to spend 25 million dollars to improve it by another 1ms. However, this article is addressing a rather specific part connected to API design. So, how can we influence the latency by API design?

Merging responses

First, let’s make a use of an example. Let’s say we have a view that says user name, age and country. Name and age are a part of /users/{id} resource:

{
  "name": "John Doe",
  "age": 25,
  "links": [
    {
      "rel": "self",
      "href": "/users/123"
    },
    {
      "rel": "account",
      "href": "/accounts/987"
    },
    {
      "rel": "address",
      "href": "/users/123/address"
    }
  ]
}

To display a country, we need to make another call, for /users/{id}/address. This means following the entire route to reach the server again:

{
  "street": "Sesame",
  "no": 25,
  "zipCode": "12-321",
  "state": "NY",
  "country": "US"
}

But since there’s no real reason to make both of those calls, let’s try to save one connection and prepare a special endpoint, dedicated for that screen:

{
  "name": "John Doe",
  "age": 25,
  "counry": "US"
}

Now instead of making two separate calls we may just call a single endpoint and get all of the required information. But remember that there is a tradeoff. To get a more robust API we’re stepping away from a REST design pattern and binding together two related entities - user and address.

Expansion

We don’t always know the way in which our API will be used. In the last example we implicitly assumed that we knew what information was being displayed. But what about cases where we design a service for future consumers which may present data in any way they decide? Yet we still want to give the option to optimize answers.

In that case an expansion pattern becomes very handy. Going to our previous example, what would this look like? We need to prepare a request that specifies which fields to display (and embed from related entities). GET /users/123 now becomes GET /users/123?fields=[name,age,address[country]].

{
  "name": "John Doe",
  "age": 25,
  "address": {
    "counry": "US"
  }
}

This is a pretty neat mechanism for merging responses, although it has it’s own limitations as well. If API consumers are using relations, we won’t be able to change the resource hierarchy without breaking clients.

Keep-alive

The closing trick is to make sure your service supports the HTTP keep-alive option. By default, all mobile HTTP clients will try to sustain the HTTP connection between different calls so it makes perfect sense to utilize this. If the server will agree to keep the connection, the next requests will omit several handshakes and directly be sent to server within an opn connection.

Closing word

In Polidea we are developing mobile apps and supporting them with backend services. The last couple of years has taught us that you may not achieve a proper user experience without slick HTTP communication. This blog post (and the upcoming “Optimizing API against throughput”) were inspired by our experiences from real-world projects. As always, we welcome any feedback and would be happy to discuss this topic as well as our work in further details.

share


WojtekHead of Engineering

LEARN MORE

Contact us if you have any questions regarding the article or just want to chat about technology, our services, job offers and more!

POLIDEA NEWSLETTER

Sign in and expect sharp insights, recommendations, ebooks and fascinating project stories delivered to your inbox

The controller of the personal data that you are about to provide in the above form will be Polidea sp. z o.o. with its registered office in Warsaw at ul. Przeskok 2, 00-032 Warsaw, KRS number: 0000330954, tel.: 0048 795 536 436, email: hello@polidea.com (“Polidea”). We will process your personal data based on our legitimate interest and/or your consent. Providing your personal data is not obligatory, but necessary for Polidea to respond to you in relation to your question and/or request. If you gave us consent to call you on the telephone, you may revoke the consent at any time by contacting Polidea via telephone or email. You can find detailed information about the processing of your personal data in relation to the above contact form, including your rights relating to the processing, HERE.

Data controller:

The controller of your personal data is Polidea sp. z o.o. with its registered office in Warsaw at ul. Przeskok 2, 00-032 Warsaw, KRS number: 0000330954, tel.: [0048795536436], email: [hello@polidea.com] (“Polidea”)

Purpose and legal bases for processing:

 

Used abbreviations:

GDPR – Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016
on the protection of natural persons with regard to the processing of personal data and on the free movement
of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)

ARES – Polish Act on Rendering Electronic Services dated 18 July 2002

TL – Polish Telecommunications Law dated 16 July 2004

1)        sending to the given email address a newsletter including information on Polidea’s new projects, products, services, organised events and/or general insights from the mobile app business world |art. 6.1 a) GDPR, art. 10.2 ARES and art. 172.1 TL (upon your consent)

Personal data:name, email address

2)       statistical, analytical and reporting purposes |art. 6. 1 f) GDPR (based on legitimate interests pursued by Polidea, consisting in analysing the way our services are used and adjusting them to our clients’ needs, as well as developing new services)

Personal data:name, email address

Withdrawal of consent:

You may withdraw your consent to process your personal data at any time.

Withdrawal of the consent is possible solely in the scope of processing performed based on the consent. Polidea is authorised to process your personal data after you withdraw your consent if it has another legal basis for the processing, for the purposes covered by that legal basis.

Categories of recipients:

Your personal data may be shared with:

1)       authorised employees and/or contractors of Polidea

2)       persons or entities providing particular services to Polidea (accounting, legal, IT, marketing and advertising services) – in the scope required for those persons or entities to provide those services to Polidea

 

Retention period:

1)       For the purpose of sending newsletter to the given email address – for as long as the relevant consent is not withdrawn

2)       For statistical, analytical and reporting purposes – for as long as the relevant consent is not withdrawn

Your rights:

 

Used abbreviation:

GDPR – Regulation (EU) 2016/679 of the European Parliament and of the Council of 27 April 2016
on the protection of natural persons with regard to the processing of personal data and on the free movement
of such data, and repealing Directive 95/46/EC (General Data Protection Regulation)

According to GDPR, you have the following rights relating to the processing of your personal data, exercised by contacting Polidea via [e-mail, phone].

1)       to access to your personal data (art. 15 GDPR) by requesting sharing and/or sending a copy of all your personal data processed by Polidea

2)       to request rectification of inaccurate personal data
(art. 16 GDPR) by indicating the data requiring rectification

3)       to request erasure of your persona data (art. 17 GDPR); Polidea has the rights to refuse erasing the personal data in specific circumstances provided by law

4)       to request restriction of processing of your personal data (art. 18 GDPR) by indicating the data which should be restricted

5)       to move your personal data (art. 20 GDPR) by requesting preparation and transfer by Polidea of the personal data that you provided to Polidea to you or another controller in a structured, commonly used machine-readable format

6)       to object to processing your personal data conducted based on art. 6.1 e) or f) GDPR, on grounds relating to your particular situation (art. 21 GDPR)

7)       to lodge a complaint with a supervisory authority,
in particular in the EU member state of your habitual residence, place of work or place of the alleged infringement if you consider that the processing
of personal data relating to you infringes the GDPR
(art. 77.1 GDPR)

No obligation to provide data:

Providing your personal data is not obligatory, but necessary for Polidea to provide you the newsletter service

Refusal to provide the above data will result in inability to receive the newsletter service.

Profiling

In the process of providing the newsletter service, we make decisions in an automated way, including profiling, based on the data you provide.

 

“Profiling” means automated processing of personal data consisting of the use of your personal data to evaluate certain personal aspects relating to you, in particular to analyze or predict aspects concerning your personal preferences and interests.

 

The automated decisions are taken based on the analysis of clicked and viewed content. They affect the targeting of specific newsletter content to selected users registered to receive the newsletter service, based on the anticipated interests of the recipient.