We are a team of mobile app and web developers with a client base consisting of mostly charity and not-for-profit organisations. Building mobile apps with internal storage isn’t that uncommon and we’ve built our fair share of those. The challenge arises when we need to have a central repository of data and images that need to change constantly. We needed to be able to change banners, text and general app settings almost on a daily basis and every app developer will tell you how much we all dislike pushing updates to the Apple App Store and Google Play.
Historically, the way to solve this problem has been to build a backend API which is what most mobile developers still (unfortunately) do today.
When building a backend API for a mobile app frontend, most developers we’ve spoken to would use a MySQL database backend, PHP to build the frontend and API and the local filesystem to store files. What we found in building this type of backend is that a tremendous amount of effort was required to scope and build the database structure and then write the required PHP code to present the data as a REST API to the mobile application. Much of the effort was expended in writing the three main functions for each column of data in the DB being ‘add the data’, ‘edit the data’, and when required ‘remove the data’. This also means that every time a new piece of information was required in the application, the three insert, edit and delete functions had to be built in the code.
Now the above is complete, you don’t need to worry about much else until your application is ready to launch and you expect a large number of users requiring more grunt and thus more servers. This requirement makes your environment exponentially more complex because now you have to worry about splitting your database server out of your frontend / php server and you also have to worry about how you’re going to store your files / images that need to be fetched by your application.
The effort required to maintain this environment became greater than the effort required to maintain the mobile app. We need to focus on building apps and we need a backend that is simple to establish, simple to edit and we don’t want to edit backend code whilst working on the mobile app.
Mobile Backend as a Service (MBaaS)
We learned that rather than building our own backend for every application we deploy, there are already platforms available that claim to do exactly what we needed! We found Parse.com and were taken aback by just how stable and simple to integrate the platform is. Our mobile developers were able to read a few code examples and integrate with Parse simply and easily. It only required a few lines of code and would be fully integrated into our applications including push notifications. This was a real win for us except not long after, Facebook (the owners of Parse.com) publicly announced that Parse was shutting down and would release the server source-code to the public as an Open Source project.
So we had to look elsewhere. With parse-server being open-sourced, we noticed a number of start-ups begin offering the service in various shapes and forms. We tried a few and share our experiences herein.
What we found when trying out some of these services is that push notifications didn’t really do what it said on the box. We had a number of developers upload iOS and Android push certificates but we found that no matter what we tried, we couldn’t get push notifications working. We actually released a few applications without push notifications because of this limitation. We filed support requests and had weeks of correspondence with various support personnel to no avail.
Free doesn’t necessarily mean ‘full service’
For a few of our client’s applications, scalability was a very important factor. Whilst we received a ‘free’ account, it was designed for development only and not meant for a fully scalable, always on, highly available backend for our frontend. This meant that for us to launch the application, we would have to cough up the cash to get upgraded to a higher paying plan and the cost was far greater than the revenue being generated by any application we were developing.
Let’s face it, there’s no point building a backend if it doesn’t perform at lightning speeds. We really needed something that was instantly available and pulled data down to the users device at a reasonable pace, regardless of where on earth that user is. We found that even with some of the paid services, there were moments that the backend simply was not available or was too slow to respond. This caused our application to either timeout or take a noticeable while to load.
We gave up and built our own
As the saying goes, if you want something done right, you have to do it yourself. So we did, in a spectacular way. Through our experience building a large number of mobile apps, we had plenty of experience in hiring experienced developers. We built out a team of amazing developers with loads of AWS experience deploying robust, scalable cloud applications and built out http://octobas.com using the same parse-server source code as was released by Facebook when the Parse.com shutdown was announced.
We built Octobas.com to be the most reliable, robust and scalable backend for mobile and web apps. Push notifications should be simple to integrate into your application and easy to configure and use. The whole backend needs to be free for developers to develop on and for application owners to run their apps from for as long as they need without paying anything until the usage starts to ramp up. When the app begins to flourish in the user markets and cost is incurred, the app owner should only have to pay for what they use and they should expect the same huge scalability all the same.
That’s exactly what Octobas.com does. Developers can sign up for a free account and immediately begin creating apps at absolutely no cost. Our platform comes with some generous inclusions and as soon as you use more than those inclusions, the app owner only has to pay for what they use.