A little while ago I compiled a post on local storage options for HTML5 mobile applications, and with the recent closure of Parse I feel like now is a good time to cover the various options out there for remote backends for HTML5 mobile applications.
Local storage is fine if the data being saved only ever needs to be used by one person on one device, but if you’re creating an application where data is shared (like Facebook, Instagram etc.), or if you want to allow users to sync data across multiple devices, then you are going to reqiure some kind of backend.
Data sharing certainly isn’t the only concern, your app might also make use of things like push notifications, cloud file storage, authentication and social integration – all of which take place outside of your mobile application.
When it comes to a backend for your HTML5 mobile application, you have three main options:
- Create and host your own backend
- Use a Backend as a Service (BaaS)
- Use self hosted software
We’re going to talk through all of these options in detail. Of course, each approach will have it’s own advantages and disadvantages so you need to measure those against your goals. Some key features to consider when selecting an option will be:
- Database
- File Storage
- Offline Support
- Authentication & User Management
- Social API Integration
- Push Notifications
There might be some other features you would add to this list like analytics, but I think those are the core features developers need when developing a mobile application that requires a backend.
There’s so many options out there and I’m not going to get anywhere close to covering them all (I wanted this post to be a little more deep than broad). The options you find here are not necessarily the best either, these are simply options that I know of and use personally, or know people who use them.
With that said, let’s get into it.
1. Creating and Hosting Your Own Backend
The DIY approach. Going down this route will mean setting up everything yourself, which in general will involve:
- Setting up a server
- Setting up a database
- Creating an API to handle communication between your app and the database
That’s a very simple overview of course, there’s quite a lot of work that goes into setting up an API from scratch. The main benefit of going with this approach is that you can use just about whatever you like – PHP & MySQL if that’s your thing, or maybe you’re more of a Ruby person… Node perhaps? It doesn’t matter, as long as you can get it to talk to your app it’ll work.
Depending on your particular circumstances this might be a viable or even preferable approach, but in general I think it’s best avoided if possible – it takes a lot of work just to get set up which can easily be avoided by using one of the other options we will talk about.
Advantages of Creating Your Own Backend
- Complete control of the technology used
- Complete ownership of the application and its data
- No monthly costs for services (aside from your server of course)
Disadvantages of Creating Your Own Backend
- Still need to use another service like PushWoosh for push notifications (you can handle push notifications yourself but it’s quite the headache to set up)
- Authentication support needs to be built in manually
- Need to integrate manually with APIs
- Scaling may be difficult when you get more users
- You’re responsible for handling server down time, upgrades and maintenance
2. Using a Backend as a Service (BaaS)
On the other end of the spectrum, you can use a service which does just about everything for you. When you signup with a BaaS all you need to do is integrate your mobile application with their API – you don’t need to worry about setting up a server at all. They usually provide simple interfaces for things like data storage and retrieval, authentication, social media integrations and more.
All of this comes with a pretty reasonable monthly cost, and a lot of services even offer free tiers so you can start hacking away at your application and you don’t need to pay until you actually start getting lots of users.
There’s clearly a lot of advantages to using a service like this, but the biggest downside of this approach is that a huge chunk of your application is tightly integrated with a 3rd party service that you have no control over. Should something happen to that service then you’ll likely have to rebuild a huge chunk of your application.
You can mitigate this risk by going with a well know and stable company, but as Parse has shown you can’t even count on the biggest players in the field (and some may not shut down as gracefully as Parse did, potentially leaving you scrambling to fix your application).
There’s been a definite shift in mood of developers towards BaaS solutions after the Parse shutdown, a Twitter poll I ran shortly after yielded the following results:
Given the sudden shutdown of Parse, will you still use other backend as a service platforms?
— Joshua Morony (@joshuamorony) January 29, 2016
The wounds were fresh though and I don’t think the failure (if you can call it that, Facebook’s reasons for shutting it down are quite mysterious) of one company means the end of the whole space. I think BaaS products are great and massively speed up development time, but you just need to make sure you plan for the worst. I’d be more inclined to use BaaS for simple applications that can easily be moved if needed.
With those points in mind, here are a few BaaS options for your HTML5 mobile applications.
Firebase
Although I can’t say I’ve had a lot of experience with other BaaS services (I’ve dabbled in Parse and looked at a few others), Firebase is currently my favourite. Firebase makes it super simple to do most of things I mentioned earlier like storing and retrieving data, authentication and social media integration.
Firebase uses a NoSQL format, which for those who do not know means it doesn’t use tables or support queries like a traditional relational database that most developers would be used to. Instead, you are basically storing objects in a JSON like format. This approach is becoming very popular and I’m not going to attempt to go into detail about the differences (partly because that’s not what this post is about, mostly because I wouldn’t do a very good job of it) but I’d recommend checking out Nic Raboy’s NoSQL Podcast for more information.
One of the really cool things about Firebase is that it is real time, so as soon as a change is made to the data (a new comment is added for example), all connected clients will immediately be updated. With Firebase you’ll still need to use a 3rd party service if you want to use push notifications though
If you’re an Ionic developer and want to learn more about integrating Firebase, take a look at this tutorial. Firebase has a free plan that you can get started with.
Ionic Platform
If you read the other posts on my blog, you would know I do a lot of stuff with Ionic. Naturally, the services Ionic offer would be of interest to an Ionic developer. Currently, the Ionic platform is not really a complete BaaS solution like Firebase is – although you can keep track of a single users data, it does not provide cloud data storage, authentication and so on. However, they do provide a solution for push notifications.
To clear up any confusion, the Ionic Framework is free, open sourced, and MIT licensed. It is and always will be completely free to use. However, Ionic also offer additional servisces which they (will eventually) charge for through ionic.io.
Keep in mind that most of these services are still in alpha. The only reason I’m including this here is because a large portion of my readers use Ionic, and it is likely that this platform will continue to evolve into an even better option for Ionic developers, but for now it doesn’t really fit into the BaaS category very well.
Backand
I became aware of Backand after seeing Simon’s tutorial on integrating Ionic with Backand. In a lot of ways it is very similar to Firebase – it offers the same kind of data storage, social integrations, authentication and so on – but there are also some differences which may be important depending on your goals.
The two biggest differences are that Backand can be integrated with a wide range of databases, rather than just the NoSQL approach Firebase takes. These include MySQL, PostgreSQL, MSSQL and Oracle – but you can still also just use JSON models.
Another big feature is integration with 3rd party services, as Backand employee Daniel Naim mentioned in Simon’s tutorial:
You can check out a full list of the built in integrations here.
One downside of Backand when compared to Firebase though is that it does not have offline support. It is also somewhat newer and less mature than Firebase – there is currently a free plan (which will remain) but they are yet to announce their pricing plans.
Telerik Backend Services
Telerik is a company with a lot of cool products (like NativeScript) which I haven’t had much of a chance to play around with yet, and they also offer a BaaS product for mobile applications. As far as a feature set goes they cover just about everything with offline support, data storage, file storage, social integration, push notifications and more.
Similar to Backand, Telerik Backend Services can also connect to any existing MSSQL, MySQL, PostgreSQL or Oracle databases. If you’re coming from Parse and want a similar set of features, Telerik Backend Services will likely be a good option for you.
Although Telerik does provide a free tier for the backend services, it does require a subscription to the Telerik Platform (which gives you access to a whole suite of tools). Prices start at $49/mo or $39/mo if paid annually.
GameSparks
If you’re building HTML5 mobile games then this service might be of interest to you. When building a game the services you require are going to be a little different. You could certainly create a game using the services mentioned above, but GameSparks provides some additional services that are relevant to games.
As well as the standard stuff you’d expect (like push notifications and authentication), GameSparks also provides player management and segmentation, teams, leaderboards, multiplayer features, chat, currencies, virtual goods and more. Building support for all of these things yourself requires an absurd amount of work, so I definitely think there’s a lot of value in services like this.
Advantages of Using a Backend as a Service
- No need to set up your own server
- Support for various features out of the box like authentication, data storage, file storage, push notifications, social integration and more
- Easy scaling – as your application grows all you will need to do is pay some more money for the next tier of the service
- No worrying about server downtime or maintaining your infrastructure
Disadvantages of Using a Backend as a Service
- A large and critical portion of your application relies on a 3rd party
- Monthly costs for services
3. Using Software
Finally we come to the last option which is using pre-existing software either installed on your own server or through using a service. The options we are going to cover here are primarily for data storage, you won’t find much to do with push notifications, social integrations or file storage here.
These options allow you to create both local and remote databases to store and retrieve your data, but they are structured in such a way that it is really easy to move your data somewhere else. Even if you are using a service to host this software for you – a Database as a Service (DBaaS) – you still own all your data and can easily port it somewhere else (whether that is another service or setting up your own server) should something ever happen to your host.
This approach is basically the middle ground between doing everything yourself, and using a BaaS.
Couchbase Mobile
In short Couchbase Mobile allows you to store data locally and sync that data to a remote database when a connection is available, which allows you to create applications that work well offline. Couchbase is based on CouchDB, which is an open source NoSQL database.
Couchbase Mobile also offers authentication and authorization. You can use Facebook, Persona, basic username and password, or your own custom authentication service.
The general idea is that you install a plugin (Couchbase Lite) which sets up a local NoSQL database within your application for local storage (similar to how the SQLite plugin works), you have a Couchbase Server somewhere, and there’s a bit of software (Couchbase Sync Gateway) that sits inbetween to sync the local database to the remote database.
One of the key bits of information here is that you need a server running Couchbase for this approach, which goes back to the point I made earlier about the hassle of setting up a server. As Nic Raboy explains in this post though, it isn’t that difficult to get Couchbase set up:
Without going into too much of the history, Couchbase was formed as a merger between CouchOne (the commercial arm of the CouchDB project) and Membase (a high performance key-value database). One of the key advantages of using Couchbase over just using CouchDB directly is performance. Membase which uses memcaching was used as the core technology in this merger, and the resulting tech is of very high performance – it claims to be 4.5x faster than MongoDB.
If you want to get started with Couchbase, take a look at Nic’s tutorial for using Couchbase with Ionic.
PouchDB
PouchDB (when used with CouchDB) provides similar functionality to what we just talked about above: local data storage synced to a remote database with offline support.
One of the key differences between PouchDB and Couchbase is that PouchDB uses the browser for local datastorage, whereas Couchbase uses native databases through a plugin. However, PouchDB can also be used with the SQLite plugin to store data natively so that you can get past normal browser data storage limits.
PouchDB plays a similar role to Couchbase Lite, in that it’s just for storing data on the device itself. It still needs to sync that data somewhere, which can be anything that implements the CouchDB protocol, which includes:
- CouchDB (of course)
- Cloudant
- Couchbase Sync Gateway
- IrisCouch
- PouchDB Server
Notice that PouchDB can even be synced with the Couchbase Sync Gateway which we discussed in the last section. This means you can use Couchbase but swap out Couchbase Lite for PouchDB if you want.
CouchDB can be installed directly on your own server, or you can use a Database as a Service (DBaaS) like Cloudant. This goes back to the argument before though of… what if they shut down? This would obviously be somewhat of an issue if you were using Cloudant as your backend, but since you would just be using the generic CouchDB protocol, you can quite easily move your app to some other service or just set it up on your own server. It is very easy to replicate your data somewhere else with this set up.
Parse (funnily enough)
I think it’s a bit early to tell how good of an option this will be, but since Parse open sourced the server when they shut down you can now just run it on your own infrastructure, instead of using their BaaS product. It’s a great solution at least for the time being if you already have your app running on Parse, and Julien Renaux has already created a great tutorial on how to set up your own Parse server.
If you’re not already using Parse I wouldn’t recommend going with this approach just yet. It is open source now, but open source projects needs maintainers because the source code isn’t going to stay the same forever. I suspect we will see a lot of activity around this in the future though and it may become a viable option.
Advantages of Software Approach
- Complete ownership of your data and infrastructure
- Reasonably easy to scale
- No monthly fees (if you’re not using a service)
Disadvantages of Software Approach
- Depending which option you choose, there may be some server set up required
- No inbuilt support for social media integration, push notifications and so on
Summary
If you go with a self hosted software approach then you’re probably going to have to use another service to implement push notifications, it might be a bit harder to set up things like authentication and social integrations, and you’re going to have a bit more work on the server side to make sure it scales properly (as well as setting up a server in the first place of course). This can be made easier by using a service like Cloudant, or by using a provider that has the server side stuff set up ready to go.
If you go with a Backend as a Service then you’ll probably be able to develop a bit faster and not have to worry about setting up or maintaining a server, but you’ll need to be prepared to jump ship should the service provider close down.
If you go with a complete DIY approach, well, good luck!
So in summary:
- A self hosted approach is a bit more work, but you control everything
- A Backend as a Service means less work, but you’re exposed to more risk by relying so heavily on a 3rd party service
There’s no clear cut winner here (as is usually the case), so just go with whatever option makes the most sense for you and always make sure you have a backup plan in place for anything of importance.
Rather than just giving an “it depends” answer, which it does, I will give you my current personal preference. For now, I’ll be using Firebase or PouchDB with Cloudant depending on the project. What backend solution will you be using?