Build Better Mobile Apps: Data and API Best Practices

by Solstice Blogging
April 20, 2016

As digital technologies and experiences have evolved rapidly over the last decade, new architectural approaches and patterns have emerged in order to better support robust, performant and elegant digital experiences. The consideration and planning of integration between client and server is more important today than ever before. Below are some common patterns and practices that have emerged as a guide to building exceptional client experiences.

1. INVEST UP AND DOWN THE STACK - Building beautiful and responsive digital experiences is a two way street: You need to invest both Up and Down the Stack

If you’re thinking about building a digital experience on top of a legacy system that lacks a finely tuned and performant RESTful API you will need to make investments both up and down the stack.  At one point or another we have all experienced apps that we wish were faster and more responsive, but in almost all cases slow digital experiences can be traced back to bottlenecks on the server.  You could build the world’s fastest mobile app but if it sits on top of slow API, your mobile application users will have a poor user experience.

Example:  

Jane is a product manager for loan processing website at a large retail bank. Recently the bank has pondered whether a mobile loan application tool would encourage more users to apply for loans. While Jane loves the product she owns, she is increasingly frustrated by the fact that the website has “slow zones” where the site performs slower than she would expect. She’s asked her developers where the performance problem is and she’s been informed that “the problem exists somewhere in our API”

Jane’s boss has recently approved budget to consult an outside vendor to build a mobile version of the loan processing application. The mobile apps will serve both iOS and Android users and will be constructed on the current API and architecture that support the website today. Jane is leery about investing in any new front end experiences when she knows her APIs have bottleneck issues. She knows that these bottlenecks have the potential to create negative feedback from users based on the high latency of the existing API’s.

Jane’s fears are completely valid. Unless her boss is willing to invest in making the necessary enhancements down the stack to refactor the bottlenecks in their API, the mobile app will experience the same challenges as the website. This will result in a poor user experience.

Lesson: When investing in mobile, make sure that you have a solid foundation to build on. If you don’t, you will just be recreating existing problems on a new form factor.

 

2. BREAKUP THE MONOLITH - As demands for new digital experiences increase, look to move points of integration from large systems to a microservices architecture.

As front end channels continue to push Enterprise IT organizations to invest more into API’s, high demand and the need for scalability has created the need to break up any large system into a set of independent services. This architectural approach is referred to commonly as a microservices architecture. From simpler deployments to easier isolation and troubleshooting, a microservices architecture creates a completely decoupled API that is easier to build, deploy, maintain and in most cases easier to consume.

Example:

Lewis is the CTO of a line of business at a large insurance company. His team owns the system of record for both customer data and claims data. While his team is regularly requested to make enhancements to their existing web services for customer data, rarely do requests come in to extend or enhance the claims services. The problem Lewis’ Application Development teams have is that the current API is a monolithic behemoth. There is a single long running build process and one deployment process. Whenever changes are made for customer data API endpoints, regression tests must be run against all claims API endpoints as well. Application developers queue up hundreds of commits each week, adding tons of internal overhead for merging and testing code.

Lewis is convinced that if his team could eliminate the dependency that binds the two sets of services together, that they could save 25% of manpower per year in his Developer and QA teams. Lewis also realizes that this problem is only going to get worse as more new consumers of customer data are using his organization’s APIs.

Poor Lewis, he seems to have the monolithic application blues. If he and his team move to a microservices architecture, they could reduce internal costs, get more features to market faster and make his consumers happier by providing a more efficient product.

Lesson: If companies like Gilt, Amazon and Netflix can break up their architecture to better ensure flexibility, scalability and a more robust architecture, you can too.

 

3. LIMIT THE CHATTER - Network calls are expensive and a drain on the battery life of a mobile device. In order to reduce the API calls and network chatter, marry the desired user experience with API design to ensure the smallest number of network calls possible.

If a mobile application needs to make multiple service calls to complete a transaction on a given screen, that is a problem. When building API’s to support a front end experience, follow the principle of trying to ensure only one API call per screen. Multiple service calls will limit the responsiveness of the application and will drain the device’s battery. Streamline API endpoints and use local cache from the device to fill in the user experience outside of the API call you need to make each screen. For example, you could cache user input data and data you have received in previous API calls while only fetching data that has changed since the last update. Whenever, caching data locally, you must always be aware of what data is Personally Identifiable Information (PII) and take the appropriate steps to exclude or mask that data.

Example:

Todd is the Architect and Lead Developer for a large RESTful web API built to sit on top of a large ERP system. Todd and team were recently informed that an outside vendor would be building a mobile experience using the current API. Todd and team pride themselves on having a fine grained and performant API, but during the mobile development process Todd and his team notice that certain API endpoints were consistently being hit over and over again. This flurry of API activity was beginning to cause of performance issues on the server.

On top of these new server issues, testers of the mobile app complain that using the mobile app drains battery life quickly. The outside mobile app development vendor attributes this behavior to the numerous API calls that each screen has to make in order to complete a given transaction or use case in the app. The vendor suggests Todd and team consider an API design where service aggregation and orchestration take place behind a single endpoint thus eliminating much of the network chatter.

Lesson: Building finely grained services is important but API design should also consider the target use cases in order to reduce the chatter required to complete specific operations.

 

4. USE SURGICAL PRECISION - In order to build a world class modern backend, you need a surgical precision with every architectural decision that you make.

As you begin to limit the chatter between client and server, initial service consolidation efforts may create large API responses. Reducing the number of service calls is important, but it is equally important to ensure that each API endpoint response only provide the data required by the client app for a given screen. Every change you make to your backend can have an effect on your API’s performance as well as the performance of any front-end application that consumes it. Every step you make requires a surgical precision to ensure your use cases are covered and that your API provides the lowest latency possible. Common patterns and techniques to help bolster performance include:

  • response payload trimming
  • caching
  • compression
  • latency trimming

Example:

Cecelia is an Application Development Manager for a Fortune 100 Consumer Packaged Goods company that was given funding to create an API last year. The API will provide the foundation for numerous digital experiences (mobile apps, in-store displays, etc) in the near future. Her team has leveraged the existing service layers that are already in place and have built a thin RESTful API layer on top. Cecelia’s team put little thought into the optimization of the API and backend layers and focused exclusively on “exposing the data and functionality that the system provides”

Shortly after front end consumers started using the API, front end developers complained about the size of the API responses and the high latency of most service requests. Cecelia felt compelled to bring in third party API experts to explain to her what types of middleware or appliances she needed to procure in order to fix these problems. She was surprised to find out that many of the efficiencies the API needed could be gained through simple changes and some greater attention to detail including:

  • cache data that rarely or infrequently changes
  • use compression when sending responses
  • trim the size of your payloads to only provide the data the client needs

Lesson: Ensure a mindful and precise design for each API endpoint. Take advantage of low hanging fruit that will give your API the performance boost it needs.

As digital experiences continue to evolve so too will architectural approaches and practices. Take these lessons learned as a baseline for building modern digital experiences that will perform exceptionally in the eyes of your users.

 

Interested in learning more? Connect with Mike Koleno to take a deeper dive into applying these best practices.

Jobs at Kin + Carta

Chicago startup guides

LOCAL GUIDE
Best Companies to Work for in Chicago
LOCAL GUIDE
Coolest Offices in Chicago Tech
LOCAL GUIDE
Best Perks at Chicago Tech Companies
LOCAL GUIDE
Women in Chicago Tech