Should Mobile Developers Learn Backend?
Lack of backend may be a strong barrier for mobile developers on their way to success. Ok. If not a success but at least an own app in the app store.
I’ve faced occurrences when mobile outsourcing developers or even mobile outsourcing companies don’t have their own backend and DevOps capabilities and work only with the existing client’s backend or outsource it somewhere else.
Mobile backend with Restful API isn’t rocket science, is it?
A piece of shared functionality among apps is significant and not unique. So why not just use existing solutions 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 denormalized storage for performance opt (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 real-time 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
Mobile Backend as a Service
There are tons of mBaaS (Firebase, Backendless, etc.) that have been appearing and dying since the sad success-fail story of Parse. That’s the first reason not to fully rely on them.
The second is that I just don’t want to go bankrupt in case I need scaling up. Since most of the mBaaS become catastrophically expensive when the amount of users grows. Who 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.
I would like it to be written in something that I'm more or less familiar with, for example, Python. Just to be able to fix something in case of need.
Here is an exhaustive list of mBaaS alternatives. I would love to hear about your experience with any of them.
Here is my thoughts about a couple of them.
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 even 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. The community has already implemented a dashboard, push notifications, and email adapter. I haven’t tried real-time live-queries, probably they are also missing.
One more important thing you should know about Parse iOS SDK is that it cannot replace local storage (core data/realm) for your app, though it may seem so after reading the docs.
If you try, you may probably find yourself inventing some workarounds for using Parse local data storage 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”.
Baasbox seems to have all the necessary features. It keeps my soul warm because it has been written in Java. Their landing page shows that they have a lot of clients.
But unfortunately, their repository is silent like Lenin in the mausoleum and I’ve found information that the project is dead.
It’s a very interesting project with a nice set of features that are actively being contributed to.
They offer mBaaS for money and open-source backend solution, plugins, and SDKs for free. 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 a restful API for MongoDB. Maybe a good intermediate solution between a fine mobile backend and a handmade backend.
I’m sure, one day one of these server-side swift frameworks will obtain so powerful ecosystem, that will allow it to overcome other mBaaS solutions. But now, I’m waiting.
Feathers library is so hipster-friendly, that I couldn’t miss it in my post. Its feature set seems very cool, but frankly, I'm not a fan of JS in general, so that might not be the project I would keep an eye on.
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 Java.
What I liked about it is that it looks more mature, backed by powerful Apache, and has a more or less active community and a fresh repository.
- It covers the complete feature set except for server-side functions and in-app validation.
- It has also nice built-in social network features for entities such as following and nested groups that may trigger update events.
- It is used by Apigee and there is more detailed and interesting information about its scaling capabilities like this and this.
- It utilizes Cassandra, and Elasticsearch and is deployed under Tomcat.
I’ve already deployed it on my play server it and made a couple of requests for a pet project. And I have to admit that it feels pretty good!