I originally wrote this post for Crew’s Backstage blog and it originally appeared there on March 1, 2016. Special thanks to Jory Mackay for his many superb edits and improvements. Note that the original audience is non-technical app owners. I have made a few minor edits from the original post here.If you’re one of the 500,000+ app owners that use Parse—the most popular mobile backend-as-a-service (BaaS)—to power your app, January 28th was a particularly bad day. After half a decade providing app developers with flexible data storage, and everything from user authentication to push notifications, the team behind Parse announced they’d be shutting down their services.
Which should’ve come as a surprise. Since Facebook acquired Parse in 2013, they have only provided positive indications about their commitment to Parse. If you have an app developed using a Parse backend, it’s time you started looking for an alternative.
First off, it needs to be stated plainly that this most likely won’t be a quick and easy fix. The backend is a major component of your app. In many cases, the backend and the code that connects to the backend can make up as much as 50% of your app, especially if your app is a social network, messaging app, or other app centered on storing large amounts of user created data.
Changing backends is obviously a big endeavor. Luckily, you have both time and options. Parse has provided a one year window (until January 28th, 2017) in which its services will continue to operate. If you feel that your app has not yet gained enough traction to warrant a partial rewrite, consider taking a wait-and-see approach. You could wait until the late Spring/Summer with the existing backend and then begin the rewrite if your app has taken off. But keep in mind that the longer you wait, the more dangerous your situation becomes (software development is a fickle business).
So, if it’s time to move, what are your best options?
Option 1: Open Source Parse Server (or the Path of Least Resistance)
Despite shutting Parse down, Facebook has graciously open sourced a large amount of its technology. This will allow you to run your own ‘mini-Parse’ on your own hardware or your own virtualized server (through AWS, Heroku, Azure, Linode, Digital Ocean, etc…).
Unfortunately, it’s not as feature rich as Parse was/is, and of course it comes with no formal support contract. You’ll also have to maintain your own server or virtualized server, which is more than some developers/clients want to do.
But, ultimately, this option will entail the least development work/code changes.
Pros:
- Free
- Complete control of your own destiny
- Fewest code changes
Cons:
- No formal support
- Have to maintain your own server or virtualized environment
- Still missing some features other BaaS providers have
Option 2: Switch to Another Established BaaS Provider (CloudKit & Firebase)
Apple provides a comprehensive BaaS known as CloudKit. It offers many of the same services that Parse offered and its resource limits are very similar to Parse.
CloudKit backs Apple’s own services like iCloud Drive and iCloud Photo Library, so you know the infrastructure is industrial strength and unlikely to go away in the near future. There are ample tutorials and book chapters to help developers get up to speed on it.
But, there is a catch. CloudKit has no native SDK for Android (or Windows, Linux, etc…). While the recently introduced webhooks may allow you to cobble together a cross-platform solution, CloudKit is clearly designed only for iOS, Mac, and Web apps (an official JavaScript SDK does exist). If your app is only on these platforms then it may make a lot of sense.
Firebase, acquired by Google in 2014, is perhaps the BaaS most similar to Parse. Like Parse it’s backed by a big company with a great reputation in the field of big data, is feature rich, and works cross-platform.
Firebase offers realtime capabilities that make it ideal for messaging apps and also offers clearly tiered pricing that makes sense for most startups. Firebase is relatively popular and there are many more tutorials available surrounding it than some of the lesser known BaaS providers, so it is likely one of the easier options for a developer to get up to speed on. However, some developers dislike Firebase’s API.
Pros:
- Free for apps with a small userbase
- Backed by Apple or Google
- Feature rich
- Well documented
- Realtime messaging support (Firebase)
Cons:
- iOS/Mac/Web only (CloudKit)
- No built-in support for push notifications (Firebase)
- At the mercy of another tech giant (like Parse was to Facebook)
Option 3: Roll Your Own Backend
Writing a custom backend can be as daunting a task as writing a mobile app, depending on the complexity of that backend. There are a myriad of frameworks, languages, servers, and development environments to choose from. If your developer does not have previous experience writing a backend, it’s likely to be a laborious, error-prone task.
However, it’s also the only path that puts you completely in control of your own destiny (even beyond the open source Parse Server).
Your custom backend is built specifically for your app. It can include whatever features you need and you can scale it however suits your growth. However, it also means maintaining your own servers. You can somewhat get a jumpstart by utilizing cloud data stores provided by services like Azure, AWS, and Google Cloud Platform.
Pros:
- Complete control of your app’s destiny
- Customized for the features your app needs
- Cheaper to scale
- Can use cloud data stores from AWS, Azure, and Google
Cons:
- Unsupported by a big company (no Apple or Google backing your server code)
- Have to maintain your own servers or virtualized environments
- Highest development cost
- Longest development time
So what’s the best option?
Choosing what direction to take your Parse-powered app is ultimately both a technical and a business decision. Utilizing Parse’s open source solution will be the least costly in terms of both programmatic effort and maintenance costs. Porting your app to CloudKit, Firebase, or a lesser-known BaaS Provider will be costly and time consuming but will provide you with comprehensive support and eliminate the need to maintain your own server. Finally, building your own custom backend provides the ultimate in control but also will be the most costly and time consuming to develop.
If none of these sound right for you, there are a myriad of lesser known BaaS providers like Kii, Kinvey, FatFractal, and many more out there. The risk, however, is that you build against one of them and then they cease to exist. Using one of these options may make sense for an MVP but is unlikely to make sense for something you expect to scale.
You must consider the development work involved, platform needs, pricing, and your timeline. As well as the future of the platform that you’re building upon.
No option is perfect, but continuing with Parse Server on your own server probably makes sense as the path of least resistance for most apps. If you’re interested in porting your app from Parse, get in touch with me.