Enriched BaaS

You can use Backend as a Service (BaaS) to host server-side components that have been abstracted from your web app. These components include things like storage, authentication, and message sending. BaaS is a relatively new service model, but by providing off-the-shelf solutions to common problems, it allows you to roll apps much more efficiently.

Like all cloud computing technologies, BaaS is moving quickly. In this post, we review some of the progress being made, especially in a new area that we will call “enriched BaaS”. The difference between plain and enriched BaaS is the addition of polished client-side interfaces to the backend components.

The Spectrum

We’ll start by looking at plain end of the BaaS spectrum and gradually work our way to the enriched end.

Plain BaaS contrasts with enriched BaaS in that the plain frameworks don’t provide any client-side features beyond a low-level interface to the backend, whatever the kind of backend. Enriched BaaS, on the other hand, adds client-side features. Whether that’s a lightweight library, or something more heavyweight.

remoteStorage

remoteStorage is a server-side counterpart to HTML5’s localStorage. If you’re familiar with localStorage, then this description is almost all you need. If not, localStorage isn’t very complicated: it’s just an in-browser database that gets persisted to the disk, and is available from any webpage. The user may be prompted as to whether they want to allow a web app to use localStorage, and how much space they will allow it to use. From the programmer’s perspective, it’s a schemaless client-side database which stores items in an associative array.

remoteStorage is just like this in terms of usage, except that you have to specify a remote location for the data to be stored. The remote location is a server that runs the BaaS server-side counterpart of the remoteStorage front-end. The server-side app can run in a choice of languages—JS through Node.js, C (POSIX), PHP, or Ruby—and can persist to a number of different underlying databases.

Since remoteStorage is just a simple substitute for localStorage, it can be considered a plain BaaS app. Of course, “plain” doesn’t mean it’s not useful! One of the great things about remoteStorage is that it not only provides you with a device-independent storage solution, but it also lets you control where your data is stored. It potentially allows your users to bring their own storage provider to your app, for example, which means that user data is federated—a feature which is becoming increasingly popular.

One drawback about remoteStorage, however, is that it doesn’t automatically synchronise to a local cache if you want to build an Offline First app.

Sockethub

Sockethub is a messaging framework. It converts several existing protocols (e.g. SMTP, Facebook, Twitter, XMPP, IRC, WebFinger) into WebSocket interfaces. You probably didn’t even consider some of those as protocols. You can think of Sockethub, then, as a kind of Babel fish translating lots of different protocols to WebSockets and vice versa.

Because Sockethub enables these protocols over WebSockets, it means that you can use them in a web app. All of this has to run on a server somewhere, so again this is a kind of BaaS framework, and once again it comes with JavaScript frontend. The frontend is a bit more complicated than remoteStorage, due to the nature of the framework, but it’s a fairly straightforward idea. Sockethub requires Node.js, and uses Redis for backend storage.

PouchDB with Janus

PouchDB is a client-side database, inspired by CouchDB, that syncs with CouchDB compatible backends. In other words, you can sync a remote CouchDB database to the browser, update it in place, and then sync back when you’re ready. You even replicate data bidirectionally!

By itself, you can use this to build client-side applications with remote persistence. This is exactly like using remoteStorage, but with the addition of CouchDB’s powerful replication and querying features. We can further enrich this by using Janus: a client-side Mozilla Persona based authentication featureset on top of CouchDB.

Janus is experimental software, but you can try out a demo. One great things about PouchDB and Janus is that it shows us how we can enrich plain BaaS setups in a modular fashion by plugging in various additional features. The same could, of course, go for the other plain BaaS layers such as remoteStorage and Sockethub.

PouchDB and Janus is a very lightweight solution. You’ll need to bring your own JavaScript framework, and you can’t do things like send emails from the front-end.

deployd

In their introductory documentation, the deployd developers call their framework an “API engine”. The analogy they use is a game engine, where database collections are sort of like sprites, and their frontend dashboard for controlling the collections is a bit like a level editor. You can think of it as “an expressive interface that lets you create your app’s API visually.”

Though deployd is a database-oriented BaaS framework, it can also act like a messaging router. It uses Socket.IO for this behind the scenes, which itself primarily uses WebSockets, though it can also degade gracefully to other alternatives. It allows you to do authentication, a bit like Janus, but there are also other capabilities such as email, provided through modules. You can also make your own modules.

Hoodie

Hoodie is a full “batteries included” framework for front-end app developers. To do this, it abstracts away everything you’d need a backend for: persistence, account management, authentication, email, and so on. And it provides a plugin system for Node.js modules, so you can extend it however you like.

Because Hoodie builds on top of CouchDB and it’s data sync system, all Hoodie apps are Offline First by default without any extra work for the developer. There are many other features in the pipeline for Hoodie too, such as payment processing and authentication using external accounts. The long-term goal of the project is to enable non-technical users to be able to make applications, much like the great days of HyperCard and its ilk.

Conclusion

BaaS doesn’t have to be constrained to the server-side. It makes sense to enrich the client-side counterpart as much as possible, because the only reason you’d have BaaS in the first place is to make frontend development easier. This realisation is driving many efforts—such as Janus, deployd, Hoodie and others—to greater heights of utility.

You can host BaaS layers yourself, or use an existing service. But for an optimal blend of convenience and control, we recommend deploying an open source framework on a PaaS provider. Deploying BaaS on PaaS allows you to customise, modify, and scale your backend service as needed, and significantly reduces vendor lock-in.

In case you missed them, The Client-Server See-Saw and Backend as a Service are the previous installments in this series.

P.S. How about you? If you’ve used any of these frameworks, or you have any opinions on BaaS and especially enriched BaaS, please let us and the rest of our readers know! Throw us a comment using the form below.