Best Use of Mobile Back-ends

Today I will talk about what I think is the best way to use mobile back-ends. With mobile back-ends I mean services that your apps can connect to for shared information and functionality. First I will go through what that functionality can be, and then I will give some examples of the most popular mobile back-end services, and also how I think they should be used.

As I’ve shown in some of my previous videos, it’s fairly simple to set up your own server and services in the cloud. But if you want to avoid the work that goes into implementing and maintaining your own server, you could make use of the many mobile back-end services that provide much of the functionality that a mobile solution needs. That functionality can be things like storage of data and files, push notifications, analytics, and last but not least, server-side logic. I will come back to why I think the logic piece is important.

Some popular mobile back-ends are Apigee, Appear, Backendless,, CloudMine,, FeedHenry, Kii, Kinvey, Parse, Mobile Apps on Amazon Web Services, Google’s Mobile Backend Starter, and Microsoft’s Azure Mobile Service. What they offer differs, and so does their pricing, but most charge for number of requests (the logic is that if your app is popular, you get more users, and they make more requests, so you have to pay more). One thing that most of them also have in common is that you need to adopt a client-side SDK that handle the connection to the back-end service. This is important to remember, because it makes your integration with the server-side specific to that service, and it will make it harder to switch service provider in the future. In contrast, if you build your services using standard interfaces, like simple HTTP requests that return JSON, as I’ve shown in previous videos, you are free to use any cloud provider to deploy those services.

One service which is very common is the storage of data, and most of the mobile back-end services provide simple ways for your app to create, update, delete and query data. But here comes my main concern, because I don’t think it’s a good idea to use that kind of service, and the reason is the same as why it’s not a good idea to use a pure REST service (as I’ve also talked about in a previous video). It all comes back to the purpose of omnichannel services, and that is to serve a number of different clients with the same functionality. If you only use the server to store data, you have no other option than to implement the logic on the client side (in the app). That becomes a real problem when you want to use the same functionality on different platforms, because then you would need to implement the same logic on each client platform. Not only would that mean extra work in both initial implementation and maintenance, but it would be really hard to make sure the logic is the same in all channels.

Instead, I suggest implementing the logic on the server side, and as it turns out, most of these services offer the ability to do that (even if their getting started samples often miss this point). For example, the Parse service offer something called cloud code and cloud functions (, and a nice detail is that it creates a clean, non-proprietary, HTTP interface that returns JSON. The cloud functions are implemented in JavaScript, which is very common with most of these services.

So if you are using any of these mobile back-end services, makes sure that you implement your logic on the server-side rather than on each mobile platform (i.e. in each app).