Why your next mobile app should use Backend as a Service
Guest blog provided by Sidney Maestre, a Platform Evangelist, from StackMob, a leading provider of backend services for mobile developers. AT&T’s APIs are being offered in the StackMob Enterprise Marketplace, which StackMob designed to support larger enterprise-level organizations that need a simple and effective way of building and deploying full-featured mobile applications.
Highly effective developers know one thing. Identifying tools and services that increase productivity are key to success. If you haven’t have heard of Backend as a Service before, this article will break down what it is, how it works and why you should build your next mobile app using BaaS.
For more tips – Download 5 Habits of Highly Effective Developers eBook.
What Is Backend as a Service?
Backend as a Service (BaaS) provides developers with server side data storage, user authentication, social integration, push notifications, and much more. All this is possible without having to write and maintain the code behind these services. BaaS companies provide an API that developers can access via a mobile SDKs. This makes a lot of sense for developers who are distributing their apps through an app store and want a simple and secure way to store and share data between devices and users.
Mobile developers have found BaaS services the fastest and least expensive way to add backend services to their apps. The APIs provided are RESTful and therefore accessible by other platforms (PHP, Ruby, Java, Unity, etc). Most BaaS provider SDKs have a mobile first approach, the RESTful nature of the APIs provide flexibility developers appreciate.
Kicking the tires is easy. You’ll sign up for an account, create an “app” on the service, then download the mobile SDK of your choice. Getting started guides will help you configure the SDK and start saving and retrieving data.
BaaS companies are focused on rapid development. One of the ways this is accomplished is through “schema inference” or “dynamic schema generation.” Schema inference allows the developer to pass an object to the API which in turn looks at the properties of the object and dynamically creates a schema. Schemas are similar to a table in a database. Of course, “schema inference” is enabled during development, but not production. You wouldn’t want to mistakenly change your schema on a live app. BaaS providers provide access to your schemas and data through a dashboard. From the dashboard you can manually create and modify schemas during the development process.
You may wonder how does an app identify itself? This is done through a set of API keys. Each app you create will have a unique API key. You’ll initialize your SDK using this API key and receive an access token. Each time you save or fetch data, you’ll pass the access token. BaaS providers take different approaches to authentication. Some use basic authentication and others use OAuth.
Many developers want to control access user data. For example, you might create a new social network (like Twitter) which includes the concept of public messages everyone can see and private messages between two users.
First, you’ll need a way for users to login and establish an identity. Thankfully, BaaS providers include user management in their offerings. Your users can signup, login or even use existing social identities from Twitter or Facebook to login. Any objects created will be owned by the logged in user. This opens up the ability to set access controls.
For example on StackMob, developers can lock down each action (create, read, update and delete) on each schema. You can set them to open or restrict access based on the user’s logged in status or if they created the object. In addition you can secure data through developer defined roles or the user’s relationship with the object.
I’ve created a sample app on StackMob called Hollagram. It’s a social network with public and private messages. Shouts, public messages, have a schema set to open. Whispers, private messages between two users, have a schema with read permissions set to a relationship with the user schema. Any time a new whisper is created, the usernames of the sender and receiver are added to the relationship field.
You can try it out. Just click login, then signup and send me a private message @ “sidney.” (By the way, this HTML5 app is hosted on StackMob’s servers).
BaaS companies tend to set pricing in two different ways. They are usage and value pricing.
Usage pricing means the cost is tied to some usage metric. This might be the number of API calls, amount of data stored or number of users of your app. They often have tiered packages which begin at free for a limited amount of usage. For example 1 million API calls per month are free, beyond that you’ll pay $200/month for 15 million API calls per month.
Value pricing means paying for features that add value to your app. This is the approach StackMob has taken. We don’t count API calls or users so we don’t charge you incrementally. Our reason for doing this is the marginal cost for each additional API call is negligible and our customers were spending a lot of time rewriting their code to minimize API calls. Definitely, not the way you want to spend your time. Instead, we offer the StackMob core API for free and charge for features through a marketplace. You only pay for the features your app needs.
All the features I’ve mentioned are what defines a Backend as a Service provider. Custom server-side code is one of the differentiators between BaaS providers. The ability to deploy custom server-side code is a big one. Many apps need a way to perform some business logic, connect with 3rd party APIs or secure intellectual property. Game developers, Flying Monkey Interactive, recently launched “Strangelings.” The game is based around genetic breeding of animals where unique animals can be sold at auction for real money. They knew a hacked client would ruin the game play and chose to leverage custom server-side code to control the unlocking of recessive genes in the animals.
Other features you’ll want to look for is separate development and production environments for your backend. The ability to deploy multiple concurrent production APIs. This is necessary if you change your schema or custom server-side code in a way that breaks the previous version of your app. Having a way to support backwards compatibility of your app is key to any business built on BaaS.
Build vs Buy
There are advantages to rolling your own backend solution. Most important is ultimate control over all aspects of your backend. You have complete choice over which OS, programming language, database, hardware, etc. and if you need that level of control over your backend, then you really don’t have a choice.
Probably, the worst reason to roll your own solution is that you’re team has done it before and it’s “easy” for them. You won’t want a cheap hosting service, so that leaves building your own or using a cloud provider like AWS. Building your own servers and hosting in a data center is very expensive. You could go with cloud hosting which typically runs $6K to $60K per year as your app scales up. Don’t forget the engineers you’ll need to build and maintain the code running on these servers; they don’t come cheap.
Evaluating the requirements of your app and understanding what is possible with BaaS is important. You can end up saving a lot time and dollars, which can help support the development and marketing of your mobile app.
You are on your way to becoming a highly effective developer.
To connect with Sidney Maestre you can find him speaking at conferences, meetups and hackathons or online teaching jQuery Mobile for Beginners and Backbone.js + StackMob. Follow him on Twitter and Github at @SidneyAllen