Built.io joins Software AG! Read all about the news.

Built.io Blog

Best Practices For Mobile Application Infrastructure: APIs, Microservices and Continuously Rewriting Your Platform


This article first appeared on RT Insights.

The mobile app development world is simultaneously stabilizing and continuously evolving, highlighting some major changes 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 up to the continuous model yet, in just a few years it will be.

Migrate To APIs And Microservices

Over the last few years, we’ve seen a growing number of applications breaking out of the traditional app bond. 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 2-3 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 application and embracing interoperability with different systems. This process has allowed companies to build both rich, segmented experiences, and to layer in additional information and data points from other services.

It’s now common to use 5-10 outside services (AKA microservices) when building anything instead of wasting time reinventing the wheel or building something from scratch. This lets you focus on building what’s next instead of making improvements to a minor part of your service, just benefit from someone else’s work.

By relying on a stack of microservices you trust, you can focus on building for the future. A core tenet of being a good engineer is to be ‘lazy’ – in other words, don’t do things from scratch – so that you can build better and faster. – Gal Oppenheimer

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 Yelp – from the moment they start researching until they’re dining.

Applications will soon be taking the next step, leaping off the mobile screen completely. We’re already seeing some adaption on Apple TV, Carplay, 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, you can be ready for it no matter what.

Our industry rewards major rewrites and starting 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. That approach isn’t practical for most companies and is extremely expensive. To top it off, every time you launch something from scratch, due to impending timelines, features are temporarily removed. Instead, we recommend staying away from these news-juicy decisions and making a more pragmatic decision.

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 periodically. This process allows you to continuously 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 (and Google followed suit shortly after) by introducing a brand new mobile OS. Although this was based on technology that was nearly 10 years old (Mac OS X), Apple had consistently updated and rewritten portions of their desktop OS so that they could put it on a hand-held device with a reasonable battery life as opposed to the industry standard for “smart” mobile OSes at the time.

Over the years, both Apple and Google have consistently rewritten entire aspects of their OS including UI, UX and actual core elements of the OS. Industry leaders have followed the same practice to stay ahead of their competition, rather than just iterate slowly over time. For example Uber has completely transformed their user experience with their latest mobile update in November. This has allowed each of these companies to continuously transform and revitalize the platform as technology, and, more importantly, user activity patterns have changed.

It’s impossible to continuously upgrade an existing system without hitting upper bounds after a few years, and so rewriting a platform – or a least aspects of it – are crucial to its continued success. – Gal Oppenheimer

Our Transformation At Built.io

We’ve employed this practice ourselves. Built.io Backend, our Backend-as-a-Service which launched in April 2013, is currently on version 3.1. It has gone through two major rewrites since we began developing it over 5 years ago. The platform was originally developed on MongoDB and RoR. In our first major rewrite, we replaced RoR after pushing this architecture to the 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.

Technology is constantly improving. If your primary goal is preserve the status quo and limit change in your technology stack, you’re holding back your customers and missing out on the opportunity to innovate. – Gal Oppenheimer

Built.io Flow was 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 user experience based on usability insights gathered during the first year of Built.io Flow being generally available. We’re continuing to iterate on this experience and have more major improvements coming soon. It’s important to remember in this case that in addition to building and improving on the features of the platform, we’re also focusing on making them faster and easier to use.

We so deeply 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.

Popular Posts

Subscribe to our blog