5 min read

Backendless Pain of Mobile Developer Pt.1

Backendless Pain of Mobile Developer Pt.1

Lack of backend may be a strong barrier for mobile developer on his way of to success.

successful mobile developers

I’ve faced occurences when mobile outsourcing developers or even mobile outsourcing companies don’t have their own backend and devops capabilities and work only with existing client’s backend or outsource it somewhere else.

I’m mobile developer and I want backend to work by itself and hurt me no more.

Johnny Cash — Hurt

Mobile backend with restful API isn’t rocket science, is it? Piece of shared functionality among apps is significant and not unique. So why not to find and use existing solution and save up to 50% of time and nerves.

99% of what we need is:

  • Entities CRUD operations
  • Relations between entities
  • Nested entities capabilities and denormalised storage for performance opts (sometimes)
  • Raw data storage for images, video, etc. Cool if extendable with external plugins
  • Auth routines with 3rd party social networks integration.
  • Users roles for creating ACLs
  • Push notifications. Cool if with user-to-user push capabilities.
  • Websockets engine for realtime needs like chats
  • Way to extend it with server-side scripts and functions
  • In-app purchase server-side validations
  • SDK no matter, restful http api is enough

There are tons of mBaaS (firebase, backendless, etc.) that have been appearing and dying since sad success-fail story of Parse. That’s the first reason not to rely on them, the second is that I just don’t want to pay. God knows, what if the app takes off. So I also want it to be open-source to feel free to deploy on my server and for the community to fix bugs)))

It’s my own peculiarity, but I’d like it not to be written in JS. Python is also awful, from type safety point of view, but at least I know python.

Here is an exhaustive list of mBaaS alternatives. Feel free to share your experience with any of them.

I‘ll also share my thoughts about a couple of them.


when Zuckerberg is calling

You may feel confident in Parse because you may think that the open-source version is the same that was deployed on the service itself. This is surprising (and may probably get you angry one day), because the docs are the same, but parse server is not. By the way, these guys reinvented the original parse service.

Here is an almost correct list of what is missing in the open-sourced version. Analytics, in-app purchase validation, server-side jobs and functions are the most disappointing missing features. Community has already implemented dashboard, push-notifications and email adapter. I haven’t tried realtime live-queries, probably they are also missing.

One more important thing you should know about Parse SDK is that it cannot replace local storages (core data/realm) for your app, though it may seem so after reading the docs. If you try, once you may probably find yourself inventing some workarounds for using Parse local datastorage and queries cache. And you will probably end up with your nerves hurt and coredata back in your project.

Unfortunately, I’ve got a project that utilizes open-sourced Parse server and maybe one day I’ll write a post, named “disappointing how-to articles about Parse scalability”.


Baasbox seems to have all necessary features. And it keeps my soul warm because it has been written in Java. Their landing page shows that they have a lot of apps, api calls etc. But unfortunately, their repository is silent like Lenin in mausoleum and I’ve found information that the project is dead.

Lenin’s baasbox


It’s very interesting project with a nice set of features that’s actively being contributed to. They offer mBaaS for money and open-source backend solution, plugins and SDKs for respect. The server itself is written in Go (not bad!) and server-side scripts API in python (not bad!)

I’m definitely going to keep an eye on it and maybe try one day.


I’ve also found it interesting, though it’s just restful api for mongo db. May be a good intermediate solution between complete mobile backend and handmade backend.

Vapor, Kitura

I’m sure, one day one of this server-side swift frameworks will obtain so powerful ecosystem, that will allow it to overcome other mBaaS solutions. But now, I’m waiting.


Feathers is so hipster-friendly, that I couldn’t miss it in my post. It’s feature set seems very cool, but God saves me from JS, that’s why I will never keep an eye on it.


Though Usergrid seems a little bit heavy-weight, it is the BaaS I’ve finished my research on.

It’s claimed to be the least hipster-friendly BaaS ever. It’s developed by apache, open-source since 2011 and written in (suddenly!) Java and probably well architected.

What I’ve liked in it is that it’s old (maybe stable), backed by powerful Apache, has very active community and fresh repository.

It covers the complete feature set except server-side functions and in-app validation, that I’m going to implement myself probably as a tiny microservice.

It has also nice social network features such as following and nested groups that that may generate updates feeds and events.

It is used by Apigee and there is more detailed and interesting information about it’s scaling capabilities like this and this.

It utilizes Cassandra, Elasticsearch and is deployed under Tomcat.

I’ve already deployed it on my server(!) and made a couple of requests in a pet project. I’m going to write about my first adventures with usergrid starting with deployment story.

If you are interested in it and want to test, but don’t want to waste time on deployment, feel free to contact me and I’ll give you test access.