Backend as a Service

Servers and clients have alternated as champions in the battle for developer attention ever since the server-client model of application development began. The mobile era saw servers in the ascendancy as cloud computing was cheap and mobile clients were underpowered, but technology gains are starting to bring mobile hardware into parity. This, amongst other factors, is driving a return towards more client-side computing.

With clients taking on more tasks, app developers are naturally thinking about ways to minimise dependence on, and interaction with, the server. By reviewing existing cloud service models, it’s possible to derive a whole new service model that assists with this minimisation, and that also introduces a range of further benefits.

Service Models

The idea behind any “aaS” (as a Service) style acronym is that service dependencies can be converted into a kind of purchasable commodity. This is great for providers, because whole companies can be formed around these services; and it’s great for users, because it means faster development through outsourcing, and low prices through competition.

Existing cloud computing service models include Infrastructure as a Service (IaaS), which provides infrastructure (e.g. servers, VM images, load balancers), and Platform as a Service (PaaS), which provides a platform (e.g. OSes, varnish cache, databases). The range of currently available service models developed from the most basic dependencies first. Before PaaS was available, you had to roll your own platform on top of the IaaS, and then you built your app on your custom platform. And before IaaS was available, you had to run your own infrastructure, then your own platform on the infrastructure, and then build your app on the platform that you run on your infrastructure. Needless to say, IaaS and PaaS are popular.

These days, then, the old complicated mess is replaced by the single step of running your software on top of the platform. Some of the software faces the user, and that makes up what the user would describe as the “app”. But really the app depends on all of these levels, from the datacentre that hosts the hardware right through to the user’s client. Even the software can be made into a service, and indeed, many app developers are building a Software as a Service (SaaS) offering of some kind.

It’s tempting to think that the next level up from PaaS is your app, or SaaS offering. But most apps are split in two: the client and the server. And if we move all of our custom code to the client, the processing that happens on the server can be packaged up as a generic service. We call this Backend as a Service (BaaS).

The Rise of BaaS

Though the current balance of task allocation is shifting back towards the client-side in many problem domains, the server-side cannot be ruled out entirely. Some services absolutely depend, for a number of reasons, on remote servers. Authentication is one common requirement. Another is access to a centralised proprietary service, such as automatic language translation. Even a task as simple as sending an email still requires a server, and one which is moreover established as a trusted entity so that its messages aren’t blocked.

Still, with the status quo between server and client changing, the client does become a natural place to solve various existing problems faced by app developers—such as connectivity, responsiveness, and device proliferation. And whilst we’re doing that, why not abstract the server side so much that we only need to call it as a remote service?

This is where BaaS comes in.

BaaS not only makes app development more efficient, but it can also help us to attack the problems that server-side bias has introduced. It is possible, for example, to bake features into BaaS that ease the transition between a connected and unconnected device, providing graceful fallbacks when the network goes down. To what extent such features are implemented depends on the specific BaaS framework.

Beyond BaaS

The ideas behind BaaS don’t stop at providing a backend as a service. Related movements seek to push BaaS to the limit. Offline First, for example, champions the notion of native connectivity handling, with apps designed to be resilient from the outset, not handling network connection problems only as an afterthought. Similarly, the noBackend philosophy extols the virtues of minimising server-side components. Whilst recognising that servers cannot be replaced entirely, adherents to this philosophy advocate condensing existing APIs down to a minimal generic set of services—much like the unix philosophy, but for the cloud and designed from the needs of applications developers backwards, and not from the backend technology forward.

Incorporating a unix philosophy for the cloud means that through BaaS you can deliver a Service-Oriented Architecture (SOA), where network-based services used by a client are isolated and made as reusable as possible. Using an SOA has advantages such as helping to combat the problems introduced by device proliferation, by promoting usability of individual services across a wide-range of devices. It also makes your whole product easier to document and easier to understand. This helps to get new engineers up to speed. Such code is less likely to rot and more likely to be reusable in future products.

Conclusion

BaaS is a natural extension of existing cloud service models, though unless you roll your own framework on an existing PaaS you will find significant vendor lock-in. Either way, BaaS allows app developers to roll an app more efficiently and in a way that works with modern development approaches like Offline First and noBackend. Moreover, when you modularise your apps, you’re able to reuse components in new products, making the development investment really pay off.

Have you used or installed a BaaS framework? Perhaps you even develop a BaaS framework and want to share your insights? Well, please let us know in the comments, because we’d love to hear from you!