Best Practices for Mobile App Infrastructure: APIs, Microservices and More

PinIt
Global smartphone apps icons splash

If you haven’t begun (or completed) a transformation to REST APIs and microservices, get started right away.

The mobile app development world is simultaneously stabilizing and continuously evolving, resulting in some major changes as of late. There are two best practices to consider when working on your mobile backend infrastructure strategy to set yourself up for success in the coming decade. First, plan for the unknown by building a flexible API-focused architect based on a pluggable, microservices approach. Next, work toward continuous development and deployment. Though mobile web development isn’t quite considered a continuous model yet, in just a few years it will be.

1. Migrate to APIs and microservices

We’ve recently seen a growing number of applications break out of tradition. On iOS for example, applications can share “sheets” that are accessible in other apps for editing and sharing content. Furthermore, you can put widgets with key information directly on the lock screen so users don’t even need to unlock their applications. We no longer believe that one single point to access information or make changes is the right way to go. Instead, put the two to three most crucial features at users’ fingertips.

Behind the scenes, most technology companies have completed the transition to RESTful APIs and are embracing microservices, the next step toward breaking apart the mobile app and embracing interoperability of different systems. This process has allowed companies to build rich, segmented experiences, and to layer in additional information and data points from other services.

Today it’s common to use five to ten outside services (AKA microservices) during app construction, instead of wasting time reinventing the wheel. This lets you benefit from someone else’s work and focus on building what’s next instead of making improvements to a minor part of your service. By relying on a stack of microservices you trust, you can build for the future. A core tenet of being a good engineer is to be ‘lazy’ so that you can build better and more quickly. In other words, don’t develop from scratch.

For example, Yelp improves its customer experience by layering relevant details such as weather, directions, reserving Uber rides and local holidays on top of restaurant details so that a user never needs to leave the Yelp app. From the moment a customer begins researching until they’re dining, the user experience in the app is seamless.

Applications will soon take an even further step—leaping off mobile screens completely. We’re already seeing some adoption through Apple TV, in-car play, bots, VR headsets and more. A microservices approach to development will give you the power to build exactly what you need on any platform since an API is agnostic to the final output. So while you may not know what you want to build next, using microservices will make sure you’re prepared.

The thing is, historically the tech industry rewards major code rewrites and starting projects from scratch. Every two years you hear about how LinkedIn is launching a new application or website built from the ground up and embracing new technology. But that approach is extremely expensive and isn’t practical for most companies. Furthermore, each time a new project is launched, features are temporarily removed because of impending timelines. It’s crucial to make decisions in a pragmatic fashion.

2. Continuously rewrite your platform

If you haven’t begun (or completed) a transformation to REST APIs and microservices, get started right away. This is the first and most important step to keep your platform ahead of the game. Even when you’ve completed this process, your work isn’t done. Across the software industry, one major factor in staying competitive is continuously reassessing and rewriting your underlying platform. This process allows you to periodically upgrade an existing system without needing to pause and start from scratch, avoid hitting upper bounds and, most importantly, fix critical bugs that may remain in older pieces of software.

How major companies have rewritten their platforms

Nearly 10 years ago, Apple upended the industry (followed by Google shortly after) by introducing a brand new mobile operating system (OS). Although it was built on existing technology (Mac OS X), Apple had consistently updated and rewritten portions of it. This allowed Apple to easily move the code to live on a hand-held device with a reasonable battery life, as opposed to the industry standard for “smart” mobile operating systems at the time.

Over the years, both Apple and Google have consistently rewritten entire aspects of their OS including user interface (UI), user experience (UX) and other core elements. Other industry leaders have adopted similar practices to stay ahead of their competition, rather than just iterate slowly over time. For example, Uber completely transformed its user experience with its latest mobile update in December. As user activity patterns evolve, the ability for technologies to continuously transform and revitalize is very important.

It’s impossible to continuously upgrade an existing system without hitting upper bounds after a few years, so rewriting a platform – or at least aspects of it – is crucial to success.

Mobile app infrastructure: our transformation at Built.io

My company has also adopted this methodology. Built.io Backend, our Backend-as-a-Service which launched in April 2013, is currently on version 3.1. It has had two major rewrites since we began developing it over five years ago. The platform was originally developed on MongoDB and Ruby on Rails. In our first major rewrite, we replaced RoR after pushing the architecture to its limit.  We essentially rewrote the underlying architecture in Node.js, incorporating the lessons learned with the previous platform iteration and rebuilding using the latest technology. This brought calls that were taking 200 ms down to under 20 ms. Two years later, we upgraded our architecture to enable a pluggable environment with direct access and customization of the DB, taking advantage of major updates in MongoDB 3.

Built.io Flow launched one and a half years ago and has already undergone two major UI rewrites: first to move from AngularJS to ReactJS, which boosted load times about 10X (twenty-plus seconds to sub-2-second load times), and then again to improve the UX based on usability insights gathered during the first year of Built.io Flow generally availability. We’re continuing to iterate on this experience and we have more major improvements coming soon. It’s important to remember in this case that in addition to building and improving the features of the platform, we’re also focusing on making them faster and easier to use.

We so strongly believe in this regular rewrite process that it has always been one of the core tenets of our engineering process; it keeps our platforms both nimble and powerful. Technology is constantly improving, so if your organization’s primary goal is to preserve the status quo and limit change in your technology stack, then you’re holding your customers back and you’re missing out on the opportunity to innovate.

Learn more:

Digital process automation

Hybrid integration platforms: using the cloud and microservices

Gal Oppenheimer

About Gal Oppenheimer

Gal Oppenheimer is the senior product manager at Built.io and delivered award-winning applications from inception to onstage launch. He is responsible for Built.io’s flagship products including Built.io Backend, Built.io Contentstack and Built.io Flow. Gal manages development engagements for both enterprises and startup customers including the Sacramento Kings, Miami Heat, EMC, Twilio and more. Outside the office, Gal can be found in the kitchen with a glass of wine or sour beer in his hand.

Leave a Reply