A Summary of Backend Options for HTML5 Mobile Applications


A little while ago I compiled a post on local storage options for HTML5 mobile applications (if you want to dive a little deeper into this, Raymond Camden also recently released a book
on client side data storage), 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.

HTML5 Mobile App 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:

  1. Create and host your own backend
  2. Use a Backend as a Service (BaaS)
  3. 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:

  1. Setting up a server
  2. Setting up a database
  3. 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:

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.


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.


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:

Backand gives the developer access to server-side JavaScript code execution, allowing for functionality that depends on a secure execution environment (such as payment processing). This functionality can be used for integration with any web-based third-party services like Stripe, PayPal, Mandrill, and AWS, among others.Daniel Naim

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.


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:

You might say that it is an inconvenience to manage the servers in which software like Couchbase is installed. The reality is that there really is no inconvenience. Services like Amazon Web Services (AWS), Microsoft Azure, and so many others, have Couchbase images available and ready to go.Nic Raboy

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 (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:

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


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?

What to watch next...

  • Great post!

    One little thing though. Couchbase Mobile does offer authentication and authorization. You can use Facebook, Persona, basic username and password, or your own custom authentication service.

    With authentication and authorization in place in Couchbase Mobile you can define who can access which data.


    • Thanks Nic, I’ve updated the post to reflect that.

  • Richard Shergold

    Thanks Josh. I had used Parse as a back-end to a few mobile apps (native and hybrid) but recently switched to using IBM Bluemix. I made that decision mainly because I wanted to use PouchDB in my Ionic app and Bluemix gave me the Cloudant back-end DB I needed for that. After the Parse announcement last week I was pretty pleased that I’d started looking at Bluemix when I did. I will continue to look at other alternatives though so any articles/blogs like this one are always welcome.

  • YS

    I wonder why you neglected the AWS Mobile Hub and Azure app services. I found them less aaS like MBaaS solutions but you can use them to do push/offline sync and much more (including MALM and testing) which cannot be done on MBaaS only.

    • There’s a ton of services I haven’t mentioned here, and as I said these are just the ones I know about personally (not necessarily the best). So I encourage anyone who uses others services they like to talk about them in the comments here.

  • Whew! I was worried for a week… Life Saver 🙂

  • Didier FRANC

    I believe in the open sourced Parse backend. The source code provided is already working very well. And just that three words should make everyone crazy “Parse open source” …

  • kalyan mazumder

    Really a very helpful post
    Just one help needed,
    You said “A self hosted approach is a bit more work, but you control everything.”
    Thats true, but will you please publish an article describing the steps and infrastructure required for the same which will be very helpful to me as well as many developers like me.
    Best Regards.

  • Esteban Echeverry Perez

    Really helpful. I think I’ll go the CouchDB and PouchDB way. Tried Couchbase before, but I find it very resource hungry (and performance is not my priority). Thanks!

    • You might want to give Couchbase a try again. Long term you’ll find it less stressful than CouchDB.

  • Chris Benson

    Josh, thanks for the great blog about all the options. Many people like myself invested a lot of time and effort in Parse and assumed that they were in it for the long haul. but now we realize we have to make a move. Thanks for the insight and suggestions. I really liked how easy the parse dashboard to use and the cloud code logic… but that’s just me… i am checking out firebase and telerik and would love to hear what direction others are going to go. thanks again!

    • I know that I have a bit of bias here, but on a personal level I truly believe data as a service is a bad idea. The Dropbox Datastore API, PayPal StackMob and now Parse have all closed their doors. All three were popular data services. When these services shut down you’re left figuring out what to do next and if you have a large or successful application, making a rushed switch is never a good thing. Eats up resources, could introduce new bugs, etc. Can you be sure that Google won’t get rid of Firebase or Telerik won’t get rid of it’s product?

      This is all coming from the perspective of “what if they close down”.

      You also have to think about cost. Yes all of these data services have a free tier, but you have to remember they were designed to be a taste. Once you need more power, the prices can become quite excessive. If you’re just messing around with things, sure you’ll never need more power, but if you’re being serious about your product, then what? When you’re using a software that lets you own your data, you pay for much cheaper hardware. Amazon EC2, Microsoft Azure, etc., are all significantly cheaper than data services. Throw open source software like Couchbase on them and you’re making out pretty good.

      Hopefully my opinion made sense.


  • Luis Ribeiro

    I found this Github repo that can complement this great post.

  • moldfix

    And what about Meteor ? It is a very good open source software backend.

  • Will Holley

    Hi Josh. It’s probably more accurate to say that Couchbase is sync-compatible with CouchDB rather than being based on CouchDB (which is actively developed as an Apache project, independently from Couchbase). Couchbase have added proprietary features to the sync protocol so if you build a mobile application that syncs to CouchDB then it will sync against Couchbase but the reverse is not necessarily true. One can certainly use Couchbase Lite to sync against any CouchDB-compatible backend and, if a native mobile library is important, Cloudant Sync (https://cloudant.com/cloudant-sync-resources/) is also worth a look.

  • Itay Herskovits

    Great write-up, Josh.

    thanks for mentioning Backand of which I’m co-founder. I just wanted to point out a couple of things. First, we actually have published our pricing recently, which can be found here: https://www.backand.com/pricing. Second, offline support is in the works and coming very soon.

    Regarding Firebase: You correctly mention two important features Backand has which Firebase lacks: 3rd party integrations and SQL databases (btw, in Backand you can connect an existing database, for example from Amazon RDS). There are a couple of other differences folks may want to know about:

    1. Server-side code execution (similar to Parse’s Cloud Code)
    2. Advanced data models

    I wrote up a more detailed comparison of Parse, Firebase and Backand here: http://blog.backand.com/choosing-a-parse-alternative/

  • Very good post, Really very helpful to beginner developer.

  • stylizone

    According to festivities and Seasons, the exemplary styles of fabric do make a heart throbbing impressions in the minds of wearer. We have Lehenga, Wedding Gown visit at..
    Designer Wedding Sarees