Backend Platforms: Build vs Buy
By now you should realize your product is much more than a mobile app.
Where will your application data live? How will you support push notifications? How will you manage all user profiles? How will you integrate with other services?
These things are typically handled by a server backend system which the client app communicates with. We often refer to this as “the backend”.
Nowadays there are several companies fighting for your dollar to take on these challenges for you. A backend in the cloud. Fully managed API services.
They sell us on the idea we get to focus on our web or mobile app and not worry about all the minutia in setting up a backend environment like databases and authentication.
Is it worth delegating these responsibilities to a third party or rolling your own?
As developers who have done both, we hope to provide an unbiased opinion in regards to providers and tools.
Terms & Concepts
What’s a platform?
The word “Platform” is often exchanged for the more technical “Backend” term. They both reference the server side components which their client applications are interfacing with. I would say “Platform” conveys more of a product and used to describe cloud service offerings.
Everyone and their mama appears to have a “platform” now. I guess it makes for a real nice conversation while wearing pair of slacks.
The backend is the beating heart of your service. The orchestrator of your entire offering. Its where we keep the business rules of the application. A lot of the unsexy things like data storage and user authentication are handled here.
What are business rules?
A “Business rule” is any custom logic you program in your application that is unique to your business.
An example of this would be applying a discount on products for customers who hold memberships to your service.
When a customer checks out … we need to write some kind of logic that checks their account level, and apply a discount to their purchases if we discover they are a platinum member.
Lets think about this for a second … would it make sense to program this logic in our mobile app? …
Of course not! There are several reasons:
- We don’t want to re-write this business rule across every single app (iOS, Android, Web, etc). We just want our apps to ask the backend “Yo, find me the total for this dude”
- It would make changing this logic extremely hard. We would have to update all our applications instead of just updating some server logic in one area
- We would not be able to allow any other third party developers to use our services (we will circle back to why this important)
Buying a Backend
My first experience with a manage backend as a service was with Parse.com. I used it in college while working on iOS apps. It was great. It allowed us to quickly develop our mobile app and not worry about any of the backend systems.
I had just spent the month before setting up databases and connections for a side project which took me forever. It was awesome just how much time I saved. Being a student, it was nice to know I could develop an app and have scary things like authentication taken care of for me.
If you go to Parse.com these days you will notice something on their page. They don’t exist anymore. After graduating college, Facebook acquired the Parse startup. A short time thereafter, they shut it down. A nice thing is they open sourced a lighter version of their platform for users to migrate and host themselves, called Parse Server.
This is an important lesson for anyone opting into managed services. These services can change at any time in pricing or availability. A big name driving it doesn’t mean diddly poo. You are at the mercy of their direction.
Google provides a backend service called Firebase, but it too could be scrapped tomorrow. At one point their change in pricing caused severe headaches and empty wallets for some.
That said, backend platforms can be insanely beneficial when you are working in small groups and have limited resources. I think they really prove useful when you are prototyping an app, delivering a 1.0, or you have simple feature requirements.
Many of them support simple server side code to help with centralizing some business logic, but its 99% of the time javascript functions exposed as web hooks. This is great but not when you need to do heavy integrations with other systems.
The big problem with any backend platform is that its often too restrictive. Startups who opt into these usually leave because they outgrow the limitations the platform can provide or find they need 100% control. Startups who are truly creating new and bleeding edge technology might not find them to be a great fit. Making the hottest new to do list? Sure, go ahead.
Top Reasons to Buy a Backend
- You are 1–2 person operation, you don’t have the man power to maintain backend systems.
- Your application has limited or simple business rule requirements or is centered around the local client. (Building a mobile game app .. you just need to save scores)
- Your platform or application is not the core of your business. Put your focus where the business is. (i.e. brick and mortar shop, internal tool, etc)
- You want to prototype an early version of your product
- You are building a vanilla app. “The social platform for X” (User Auth, Data Storage, Facebook Integration … nothing too special going on)
Parse Alternatives
Rolling Your Own
Its no secret, if you build your own you will spend more time and money developing the backend piece. The follow-up question would be “is it worth investing resources into this?”.
If the core of your business is your software, then yes. Absolutely. 100%
When we think about our solution we often put all the value into the app. I would argue there is greater value in developing your solution as a platform instead of a single app. Our web and mobile clients should be consumers of our features, rather than having to deal with implementing all the logic themselves.
Is Facebook an app? I can access it on web or mobile. I can build 3rd party apps with their API. No no my friend, Facebook is “The Social Platform”.
The Power of Your Own API
An Application Programming Interface (API) is a fancy word for the magical door that connects your apps (web, mobile, etc) to your platform or backend service. It’s the doorway in which applications exchange information.
This is exactly how services like Facebook, Spotify, and Yelp are allowing developers to incorporate their services into their products.
Offering an API to other vendors and developers can be extremely beneficial to your service. You could even monetize API services once developers exceed certain rate limits, much like Google does.
Whether you are offering free or paid access to your services through an API, it can have tremendous growth opportunities as other developers bake your services it into other products.
Surely Uber never thought their service would be available in a smart mirror. But with their API, developers can build just about anything.
Top Reasons to Roll Your Own
- It is the core of your business. Maintaining all intellectual property & data is important to you.
- The app has complex business rule requirements (like machine learning)
- Technology stack is important to you (perhaps you favor a Java or GO backend)
- Heavy integrations with other custom systems
- Avoid vendor lock in. We can pick and choose who we host our project with .. Heroku, Amazon, Microsoft, etc
- Open source technology is making it easier to develop and manage backend APIs
Accelerate Backend Development with these projects:
Build Realtime apps with MeteorJS
Build Realtime apps with Horizon and RethinkDB
Somewhere In Between
Parse shutting down wasn’t all bad. It might have just been a blessing in disguise. While the service is no longer available, facebook has released a lighter self-install version built on NodeJS with MongoDB called Parse Server.
This is a great middle ground between buy and build. We can take the code and host it on any of the many platforms mentioned above, or we can modify it to our specifications. Of course you might not like a NodeJS environment or a NoSQL database. Parse-Server can be configured with a relational PostgresDB (with some caveats). It still suffers from the same problem all these solutions do in the fact it might be too generic for you.
At least with parse server we can avoid being locked into someones house.
Conclusion
Unfortunately time and money are not endless, so lets play devil’s advocate in asking the big question… does your MVP need a full custom backend? Most likely no. Hell, you probably don’t even need working software for an MVP.
When we build a minimal viable product (MVP) there may not be too much custom business logic. Often times we just want to build out an app and get it in our users hands as a proof of concept. Backend features are mostly persisting data to a database with vanilla code (login user, save this, get that).
For these cases products like Google Firebase and Parse Server are extremely attractive. Its just life after we need to really think about. Its all a honeymoon until users start logging in and the bills start rolling.
With so many tools and frameworks that make backend development easier like RethinkDB/Horizon or MeteorJS … building something thats entirely yours isn’t as bad as it used to be. One of the larger concerns will be how you manage and maintenance these backend systems. Heroku and Amazon’s Elastic Beanstalk are great for these scenarios. Deploy your code and have resources dynamically configured.
Start small and grow with your solution. If you do start with a service provider or off the shelf backend, ensure you are developing your application in a way that makes migrating as easy as possible. (Hint: its never as easy as you think it is).
