Designing Mobile First Service APIsPosted on by Akos Kapui
Mobile first design often refers to a principle that puts UI/UX designs for mobile devices before desktop web. However, the implications that come with this go way beyond the UI. A mobile first strategy requires a new approach to planning, development, UX – and it requires a new approach to API design as well. Although using the same RESTful APIs for all platforms would be possible, in reality it creates constraints for the mobile experience. The benefit of designing user-interfaces only for the web was a massive simplification and we (engineers) can easily get used to this level of comfort. This article is going to discuss design considerations for service APIs that enable teams to deliver a mobile first experience.
Mobile First Design is Outdated! Why Does it Matter Anyway?
The recent hype around bots started a paradigm shift and internet economy leaders are already talking about AI first design over the mobile first approach. This is broadly true, and businesses will need to consider adopting new principles and design methodologies. However, AI first is not contradictory to mobile first, but rather complementary or evolutionary. They both highlight the need to have different design considerations for different use-cases.
Give Me the Mobile First Checklist
If we approach mobile first design from the aspect of “what do we need to change to make it work for mobile?”, we’re already constraining the scope by only focusing on some must-have items. Practically speaking, the only thing that you would really have to do is to make the service publicly available over HTTP. This would essentially allow mobile apps to access the content the same way it is available for the web. However, this wouldn’t result in a mobile first API.
Even if you look for a comprehensive checklist which would ensure your API is designed for mobile experience, it’s unlikely you would end up having a mobile first API. Such checklist would include items such as Paging & Filtering, Embedding, Compression, Caching and optimization for data plan and bandwidth. These are very important items but would only help you optimize your API to support mobile needs and have a better general purpose API platform.
Design for Experience
First and foremost, mobile is different. This isn’t just because we have less space to show information, but mostly because people use mobile devices differently.
Imagine a travel app that tells you what to see/visit in a given city. On the web you would expect the user to enter the destination, while in a mobile app this would only be a secondary functionality as location would be picked up automatically. In the app it would be important to be able to cache some content due to lack of continuous access to the internet which isn’t the use case you would want to support on the web. You might also want to allow the user to switch language and in that case you might need to cache content in each language or download it on-demand. Also the content shown on one screen on the web would be presented in a different structure, so downloading all the content in one go might not be ideal in every use case.
This leads us to a situation where the team that maintains the general API is different to the mobile team who would be likely to come with fast changing requirements. In some cases this all might still be possible and effective to be supported by one single API, but there are couple of different solutions that would work better in other cases.
Thinking in GraphQL
Facebook was faced with the very similar issue while building its Graph API. Given the complexity of data, they’ve come up with a new approach that allows new ways for clients to fetch data. They did this by focusing on the needs of product developers and client applications.
The GraphQL architecture provides a way for developers to specify the precise data needed for a view and enables a client to fetch that data in a single network request. This helps applications to fetch data more efficiently (compared to resource-oriented REST approaches) and avoid duplication of server logic (which can occur with custom endpoints). Furthermore, GraphQL helps developers to decouple product code and server logic.
Backends For Frontends
Instead of developing and maintaining one general API there is another option: create a specific service for mobile apps. Essentially this is a business logic that is tightly coupled to the user experience. This means this service will likely be consumed by a single UI / app and that means it won’t be generic enough to be exposed externally.
This limited scope and focus, however, enables changes to allows us to adjust the need specifically for that single use case and eliminates any kind of limitation that a general API would come with. However, the biggest advantage is rather the fact that this API would likely be maintained by the same team that develops the mobile app. (Disclaimer: The name for the BFF pattern has been first introduced by Phil Calçado and this article has also been inspired the blog post written by Sam Newman.)
Mobile first design comes with the fact that we can no longer optimize for the simplicity of the system as the user experience doesn’t stop at the boundaries of the mobile apps. There is no general guidance that help you make your API aligned to the user experience as it implicitly comes with the price that every use-case is different. In Skyscanner we are betting on mobile specific APIs that are also implemented and maintained by mobile teams in order to be able to ship great features more efficiently to our users. In this internet based economy every Software Engineer is a polyglot by necessity. We’re required to switch technologies efficiently, relying on our fundamental engineering skill-set to progress. This is all important for our objective to be able to deliver personalised content and features to travellers.
Akos Kapui is Head of Apps Technology at Skyscanner, leading the engineering team responsible for native app development.
This blogpost is part of our apps series on Codevoyagers. Check out our previous posts: