Parse, a Backend-as-a-Service (BaaS) platform, allows developers to focus their efforts on building a robust front-end experience without having to worry about constructing a complex backend infrastructure. Its cost and resource-effective options alleviate many projects' need to create a database, code API endpoints, handle a push-notification infrastructure, figure out how to scale properly, etc.
Facebook acquired Parse in 2013. In 2014, Parse released a report detailing their support of over 500,000 applications. On January 28, 2016 Facebook announced that it would shut Parse down with all services ceasing operation on January 28, 2017.
This announcement left many developers, including me, needing to figure out where to go next. Essentially, anyone using the service has one year to migrate their backend elsewhere or their application will stop working when the plug is pulled. If you're like most, you haven't planned or budgeted for migrating your backend to another service. Fortunately, several options exist and migrating isn't as hard as you might think.
What are My Options?
Parse shutting down inconveniences many developers, and many alternative options do exist. From building your own backend, finding a substitute service, or spinning up your own self-hosted instance of Parse, there are a variety of options to choose from.
Building Your Own Backend
Out of the options covered in this article, creating your own backend will likely consume the most time and resources, both short-term and long-term. However, this approach also grants the highest level of flexibility, customization, and control.
Building your own backend grants the highest level of flexibility, customization, and control.
When building a custom backend, you're free to choose the technologies and frameworks that make the most sense to support your business. You don't have to deal with the traditional limiting factors that you may encounter when using a BaaS platform. Furthermore, you remove the dependency on a third party. As made evident by Parse shutting down, relying on a third party to support your business's infrastructure can negatively impact you in the long term should the service get discontinued or its product undergo a radical change.
Although this approach does give you control of your own destiny, it also comes with several negatives, depending on your team's expertise and the monetary resources at your disposal. Many developers originally went with Parse to save costs and get to market faster. A custom backend not only costs significantly more to develop, it takes longer and comes with a higher probability for error. Because you assemble the infrastructure and architect the approach yourself, not only do you introduce the human error element, but also maintenance needs. It requires an ongoing effort to keep it running at maximum potential. For instance, you have to make sure that it has the latest security updates, scales properly, manages the hardware, and monitors error logs, just to name a few new chores to add to your team's ToDo list.
Building a custom backend, however, doesn't need to be an all-or-nothing endeavor. There are several proven technologies and services to simplify and expedite that process. Again, you open yourself up to reliance on third parties but, as is the case with much of software development, you've got to run a cost-benefit analysis. Services like Heroku (more details in the sidebar) can at least alleviate some of the pressures of maintaining your own infrastructure. You still build and architect your solutions from scratch but technologies like this help solve many hardware headaches and make it significantly easier to scale up with your business.
Amazon Mobile Hub
Amazon Mobile Hub is Amazon's BaaS platform that uses existing Amazon Web Services (AWS) technologies, like AWS Cognito, AWS Simple Notification Service, and AWS DynamoDB, to help developers create robust mobile experiences. Under a single dashboard, developers can enable and configure the corresponding services that they need to power their application. Figure 1 demonstrates the dashboard that allows a developer to use an array of features, like:
- User management and authorization using AWS Cognito
- NoSQL and SQL databases using AWS RDS and AWS DynamoDB
- Push Notifications using AWS Simple Notification Service
- App Analytics using Amazon Mobile Analytics
- Cloud-based logic using AWS Lambda
- QA against real devices in the cloud using AWS Device Farm
If you've used Parse in the past, the feature offerings should appear very familiar. Additionally, many of the Amazon services, like DynamoDB for one, have drop-in client-side iOS and Android SDKs just as Parse did. However, they're not drop-in replacements. If you want to transition to Amazon, you need to reconfigure your backend architecture through the Amazon Mobile Hub dashboard and then, using the various Amazon SDKs, replace any use of the embedded Parse SDK with the Amazon counterpart. Although the functionality is similar, it differs in syntax, so this requires a sizeable amount of rework on each client-side platform, depending on the overall scope of the project.
As a result, Amazon Mobile Hub makes a lot of sense when starting a new project and looking for a Parse alternative. However, when looking at the most cost-effective migration options, other approaches exist that can get you back up and running quicker.
Your Own Parse Server
When Parse announced that it was closing up shop, it also open-sourced the Parse server, which runs on Node.js and MongoDB. If building your own custom backend or switching to a Parse substitute on short notice seems unfeasible, self-hosting your own version of Parse, at the very least, gives you time to figure out your long-term plan.
Amazon details tutorials on their website for how to migrate your existing Parse setup to Amazon AWS using AWS Elastic Beanstalk. Not only do you get the dependability of Amazon's infrastructure, but also the development effort on your existing platforms is minimal. For instance, it allows you to continue to use the Parse client-side SDKs that you already have in place, meaning that (as long as you're on the latest SDK versions) you only need minimal changes to the client-side application to continue using basic data services. If you use push notifications, analytics, or some of a few of the other offerings that Parse had, you'll have to find substitutes to fill in the gaps. Check the sidebar for links to some of the services you can take advantage of.
Similarly, on Github (links in sidebar), Parse details tutorials to incrementally configure your own version of the Parse server using Heroku and either mLab or ObjectRocket. You start by migrating only your data to a self-hosted MongoDB. From there, you can tell your existing application to start writing to your hosted DB instead of the Parse-hosted DB. Figure 2 demonstrates what the relationship looks like after phase 1, with blue elements controlled by Parse and orange self-hosted.
Eventually, after following the entirety of Parse's instructions on migrating your dependencies from their platform to your own self-hosted version, the client-to-backend relationship resembles Figure 3. In Figure 3, you have a development build running on a completely Parse-independent version of the Parse API using your own deployed Parse server and a self-hosted MongoDB instance. At the same time, your production application, still using Parse's API, has transitioned to the new MongoDB instance as well, because changing your production application's data source can be done without client-side updates. Then, the only thing left to do is push a version of the development build into production and have your users update to this build. If you've given yourself enough time, your user base will migrate to the new build and when Parse goes offline, your users will be free-and-clear of the version that previously relied on Parse.
Although this option likely gives you the shortest path to migrate off of Parse's services, you should also consider the downside to this approach. Mainly, the open source server doesn't come with all the bells and whistles that largely made Parse desirable to begin with; items such as the dashboard (Parse mentions that they're working on an open-source version), push notifications, analytics, webhooks, general application configuration, cloud code, and scheduled jobs will all need to be substituted if your application is dependent on them.
Additional Parse Substitutes
Lastly, the BaaS ecosystem has a number of players that you could consider if you've determined that you want a substitute and would rather re-engineer your client-side applications instead of taking up backend development. The following list details some of the more popular options. The sidebar contains additional links to a more comprehensive list.
- Kinvey: A BaaS platform very similar to Parse and offering cloud storage, push notifications, and custom business logic. Unlike Parse, the free tier is development-only.
- Firebase: NoSQL cloud database that specializes in real-time communication. Data is stored in JSON objects and is then synced to all connected clients in real-time.
- CloudKit: An iOS- and OSX-specific public and private cloud database that has a point-click dashboard similar to Parse.
- Microsoft Azure Mobile App Service: Similar to Parse in that it also does both offline/online data synching. Additionally, it supports user authentication, cloud code, and push notifications.
Sooner Rather than Later
Whichever approach you decide to take, it benefits you to move quickly. Parse announced that if you haven't at least migrated your data source by April 28, 2016, it would de-prioritize the traffic to your application in favor of applications that have already made that transition. They also formally suggest that you try to complete your migration off of their services by July 28, 2016.
If you haven't at least migrated your data source by April 28, 2016 Parse will de-prioritize the traffic to your application in favor of applications that have already made that transition.
The options listed in this article represent a small sample of the choices that you have to consider. If you want to check out more options, look at the sidebar for several additional resources. Additionally, when considering one of the Parse alternatives, keep an eye out, as most have tutorials specifically created to help developers transition from Parse to their respective platform.
