Do You Actually Need a Backend for your mobile app?
Probably, and choosing the right option is not that easy
A lot of companies start with a great iPhone app idea. From that point on though, starts the stress of technical decisions. “Should we use hybrid technology or go native?”, “Should the app be written in Objective-C or Swift?”, “What OS should I support?” and finally “Do I need a backend?”, “What kind of back end?”, heck “What is a backend?”.
Today I’ll cover those last three questions. I’ll talk about backends.
Do I even need a backend?
This question is very easy to answer. If you answer yes to any of the questions below, then the answer is: “yes, you need a backend”.
- Do you have any need to synchronize data between multiple devices?
- Do you want to display your user’s data on a web site?
- Do you want to offer back up for the data generated by the user?
- Do you want to be able to change your app behaviour based on your input without re-releasing the app?
- Will your user consume the content you create within your app?
What is your answer? Do you need a backend? If your answer is no, then you’re among the very few. Most applications today require some kind of backend. Consider yourself lucky, you just saved a lot of money and headaches.
On the other side, if you answered yes, then welcome to the world of app development. You’ll see it’s an exciting world with a lot of moving parts.
What is a backend?
A back end is a software that runs on a server that your application and website can communicate with. You can use this backend for lots of things:
- storing data
- sharing data
- control your app
- host content to show in your app
- run your business logic in a central place so you don’t have to re-implement that business logic in your apps
- crunch some numbers based on the data stored on that backend
Now that you have established you need a backend and you know what a back end is, let’s see what your options are.
Option 1: CloudKit
If you are iOS and web-only and all you need is to store data you can (and probably should) go with CloudKit by Apple. A lot of Apple’s apps (Photos, Notes, iCloud Drive) use Cloudkit…
1. Apple is not going to pull the plug on this.
Apple has been pretty good about supporting the technology they have included in iOS. Even if they were to deprecate it, you would have a couple of versions to migrate.
2. No user registration is needed.
Your users are already registered via their AppleID. Data will be available as soon as your user installs your app. This can considerably reduce the install friction in your app. Do not underestimate how much that can help your app user experience.
3. CloudKit JS allows seeing the same data on a web site
4. It’s free
There is no such thing as a free lunch, but in this case, you at least get a free starter.
1. No Android support.
In today’s world, this is the biggest deal-breaker for most. Even if you don’t intend to support Android today, you would be closing the door to future expansion (unless you’re ready for some workaround).
2. It can only be used for data storage.
A backend is not just used to store data. It is also used to perform business logic which you don’t want to replicate across your web site, your iOS app, your Android app. CloudKit does not offer this option and so you end up having to duplicate that logic across all your clients. Some app has very limited business logic and thus can get away with it.
Option 2: BaaS
You can go with any of the backends as a service (BaaS) that exist on the market today:
- Firebase by Google
- Mobile Hub from AWS
- Azure mobile app tools by Microsoft
- GraphCMS for CMS as a service
There are others, just make sure you pick one that won’t go anywhere (just google Parse shut down and you’ll understand why)
1. very easy to set up, makes for a cheap first version of your app
Each of those companies wants to make it as easy as possible for your developers to use their platform. The reason is that they will charge you for your usage. So it is in their best interest to keep the integration time as short as possible. This will save you some money on your first version.
2. Reduces the need for a backend developer
3. Can quickly scale up with demand
Every entrepreneur wants the same thing. They want their app to make it big and have a lot of users. With a BaaS, you don’t have to worry about your server crashing under the millions of users suddenly showing up at your doorstep. You would hit the limit of your service plan with your provider and you would upgrade to whatever tier is required.
4. Cost is super low when you start
Most BaaS platforms have a free plan to get you started. For a startup, this is great as it helps you to test out your idea with limited investments.
- The cost can quickly ramp up when your app gets popular
Remember those millions of users suddenly downloading your app. Well each of them represents a cost that you will have to pay to BaaS provider. Optimizations at this point vary based on the provider and you’ll have a hard time reducing those costs. So make sure you take a good look at the pricing structure of the BaaS provider you use and your user growth projection.
2. Your developer is tempted to put the business logic in your mobile app
As I mentioned before, it is almost easier for the developer to put the business logic into the app. It is a language they already know, no new tools to learn. That is, unfortunately, a bad idea. When you create a smart TV app or a web site you’ll have to invest in recreating that logic.
3. Those third party could close down that service (just google Parse shutdown)
This does not happen very often, but Parse.com shutdown in 2016 sent shockwaves through the startup ecosystem. Just know that changing backend in the middle of your project is not something you want to sign up for. So pick a player which has been around for a while.
4. Lacks flexibility since you can’t modify the code
When you choose a BaaS, you get married to their implementation. If they have implemented something a certain way and you’d want it to work another way, you are out of luck. Most of the time, those are only for small features and can only be considered annoyances, but for some, it might be more painful. For example, parse.com for a long time did not support offline mode and once they did it was buggy. Leaving you to either roll your own or wait for Parse.com to implement that feature.
Option 3: Hosted backend
You can go with a custom backend that runs on someone else’s cloud (ie: AWS EC2, Heroku, Azure Virtual Machine, Google Compute Engine). A custom backend is where you have a developer write your backend from scratch for you. You also end up having to write specific code in your various client to connect to your servers.
- You can do anything you want
People always ask me: “Can we do X in our app?”. My answer is always: “This is software we can do anything, but how much are you willing to invest”. With a custom backend, you can do anything you want. You just have to be willing to invest.
2. Can scale to meet demand
If you get lots of users you’ll have to provision more machines to handle the traffic.
3. You own it, you can move it to another cloud easily
A new provider just entered the market and has some fancy features you want. You can take your code, your data and migrate to another provider fairly easily. Your team will spend a few weeks planning the move and making sure everything is ready, and then one night, you’ll switch.
4. You can optimize your backend for cost when you scale up
As you get more traffic, you’ll add more machines to handle the traffic. You’ll also see your hosting bills increase. The good news is that with a custom backend you have an option to limit those bills. You can take a good look at your server and see where it is not as efficient as it could and potentially save a lot of money.
- More expensive to setup
Creating a custom backend is not something you do on a limb. It requires specific skills and will take some time. You’ll want a dedicated developer to take care of it, maintain it and monitor it. Be ready for a heavy investment up front to gain flexibility and reduce costs in the future.
- More IT headaches to deal with
Having a server means maintenance. In the custom backend situation, you’ll have to put more thought into your IT, how many machines you want, what kind of machine you want where around the globe those machines should be. Using a BaaS, for example, insulate you from most of those issues.
Option 4: Self-hosted backend
Last, but not least, you can go with a custom backend on your server in a datacenter. I won’t detail that one as it only applies to the giant companies of this world. And even those companies are now more and more renting someone else’s servers. Netflix famously uses AWS to host part of its infrastructure.
I know this was long, and I hope you have a better understanding of your options now. Feel free to ping me if you have questions
If you enjoyed this article, you might also enjoy these: