Mobile Backend as a Service

A client recently asked me about the available options for Mobile Backend as a Service offerings (mBaaS). Here are some quick thoughts. This is just an overview, but will give you a good place to start when deciding what to use.

Why to use a mBaaS

It’s not mandatory to use a commercial mBaaS, but there are some good reasons to consider it.

Serverless

Running your own server is expensive and risky, even if it’s in the cloud. You have to:

• Make sure all updates are tested and installed quickly. Especially security updates which can happen any time, even if your DevOps engineer is on vacation or drunk.
• Be ready to scale. If your app gets featured in the App Store, your traffic could multiply by 100 overnight. It would be a good problem to have, but you have to be prepared.
• Be on the lookout for attacks.
• Make sure everything is backed up, measured, and logged.

All commercial backends will handle these things for you.

Easy to get started

With a traditional database backend, you define your database tables and rows on the backend first, then code your app to use that. When you want to make changes, you have to migrate the backend data to the new structures.

All the currently available backends use NoSQL databases. That means you don’t have to define a schema ahead of time, you can just start coding on the client.

(Note: This loosey-goosey approach can also be a negative. See below.)

Client-side libraries

All commercial backends come with their own library code for iOS, Android, and the web. Their quality varies, but they typically make it easier to get your app started, compared with coding a REST interface from scratch, for example, or setting up Core Data and SQLite.

Extra features

Beyond just a syncable database, you often get things like cloud storage (S3, etc.), authentication and authorization, analytics, and crash monitoring.

No, you don’t need a full BaaS to get all these things, but it’s convenient when they’re all bundled.

Less choices to make

Once you decide you’re using FireBase, for example, you know how your data is going to sync, you know where you’re storing your assets, you know how you’re logging crashes. While not every one of these will be the ideal choice on its own, it’s nice to pick them as a bundle and not have to mix and match.

Community support

If a service is popular enough, you can reach out to the user community for answers to questions. Chances are somebody somewhere has experienced the same problem you have.

Why not to use a mBaaS

There are also some downsides to using a commercial mBaaS. Some of these are just flip-sides of the advantages, as every choice we make has tradeoffs.

Serverless

All of the commercial mBaaS solutions have limited server logic. That means all business logic lives in the app. That means duplication if you’re multiplatform. It means if there’s a bug in your iPhone app, it could cause havoc on the server.

And in some ways it just feels wrong to directly modify your database from a cell phone. Software Engineering values a strict separation of concerns, for good reasons.

Limited data migration and versioning

Releasing new versions of your app will be a pain. If you change the way your data is stored (and this always happens) you need to deal with deployment. Remember that not every user upgrades at the same time, so you will need to keep the old data around for a long time. Even still, at some point you’re going to have to force users to upgrade their app to avoid maintaining two copies of every piece of data.

And all this logic has to live on the client.

Limited or no server-side validation

An advantage of a NoSQL database is the client has direct access to store whatever it wants. A disadvantage is the client has direct access to store whatever it wants.

Vendor lock-in

When Parse came out, it was hailed as the best thing since sliced bread. Then Facebook bought it. Then Facebook killed it. Now all Parse users were left hanging. That was a sad time.

Amazon probably won’t go out of business. Google won’t either, but they have a history of canceling projects. Remember Google Wave? What if FireBase goes all Google Wave on us? Then we would be sad all over again.

Less choices to make

Once you decide you’re using FireBase, for example, you know how your data is going to sync, you know where you’re storing your assets, you know how you’re logging crashes.

Yes, I just copied and pasted this paragraph from the advantages list. You get the idea.

Hosting fees are expensive

You may consider this worthwhile, but with any of these services you’re going to be paying a lot more than if you self-hosted. This may be offset by needed less people to manage the server. It will depend on your situation.

NoSQL

The debate between NoSQL and traditional relational databases has been raging for a while. Suffice to say that a NoSQL database may not meet all your needs.

Bare minimum features

Any backend-as-a-service you choose will need to have these features:

• Database sync
• Authorization/authentication (Allowing users to log in, possibly using their social media accounts)
• Push notifications/messaging
• Cross-platform (iOS, Android, web)
• Back-end access (administrative panel)
• Good developer documentation
• Easy ability to administer and deploy

Other features

These are things you may or may not need, depending on your project.

• Offline functionality with opportunistic sync and conflict resolution. In other words, can I use all the features of the app when I have no data connection?
• Analytics, crash capturing.
• Data storage for images, videos, etc.
• The ability to run code server-side
• Complex database queries

Some current solutions

Here are some of the current commercial options, along with what I know about them. This is not every BaaS, but it is some of the more popular ones.

You’ll want to do more research to find out which ones meet your needs. And keep in mind this is a young field, constantly changing, so the best option today may be different from the best option tomorrow.

iCloud

• Bare-minimum sync functionality
• Free
• iOS and web only
• No backend access
• No cloud code
• No DB queries, just sync

Realm

• Offline-capable Document based DB with real-time sync.

Firebase

• Offline-capable NoSQL DB with real-time sync and conflict resolution.
• Includes Crashlytics
• Run by Google, for better or worse.
• Integrates with Google Cloud Storage, etc.
• Cloud Messaging for Push Notifications
• Includes analytics

Amazon Mobile

• Complex to configure
• Analytics
• Integrates with S3, other Amazon services.
• “Cloud Logic” with Lambda
• “No one ever got fired for using AWS.”

Parse

• Open source
• No offline-first story
• No migration
• Configure and manage server yourself
• Not recommended

Custom

• More work to get started
• Hosting fees are cheaper once it’s launched
• Requires maintenance and upkeep and updates
• Can do whatever you want
• Avoids lock-in.
• Can be built on top of other services, including those listed above
• Can use a relational database
• Can use your backend language/framework of choice

How to decide

Start with your business needs. Some important questions to ask yourself are:

• Does my app need to work while offline? If yes, make sure your backend handles that.
• How fast do I want to get a MVP (minimum viable product) released? If you’re in a time crunch, don’t make a custom backend.
• How fast do I expect to scale? If you want millions of users within the first year, make sure you can handle that.
• Do I need any of the extra features, like large-file storage, analytics, crash-reporting?
• Do I need to do complex queries? If so, NoSQL is a poor choice.
• Do I need complex server-side logic? If so, consider a custom back-end.
• Will I want a public API to my product? Make sure you can run it on the same server as the database.
• What is my budget? Short-term, medium-term, and long-term. For example, many backends are free or cheap for low-traffic, but get expensive quickly as you ramp up your user base. If you’re short-term budget is low, but you’ll have funding once you’ve launched an MVP, this is a good option.
• What am I currently using? If you’re already heavily using AWS, it might make sense to stick with their offering. Same with Google, or even Microsoft Azure.

Then once you pick an option, stick with it until you have a good reason not to. Avoid technological churn.

The mBaaS field is exciting right now because there are a lot of good options. The field is very very young, so keep your eyes open because the best is yet to come.