The announcement that Parse is shutting down in January of 2017 has sent many developers off on quests to find the replacement. Almost every mBaaS vendor out there has added a banner at the top of their front page, inviting us to migrate to their service and it clear that they would be happy to help out. This pervasive message has a singular underlying meaning: migration is not easy. It is not just an issue of moving data; many apps also rely on Parse’s Cloud Code to implement more complex server side processing.
To their credit, Parse is taking their own steps to help out. They have, in fact, opened up the source code of their backend server as a project on GitHub that developers can download and set up themselves. To get a better idea of the work involved in migration, we decided to try a pilot program and move one of our apps to the open source system. This exercise revealed a number of issues, which are explained further below:
First, the code being offered is a single tenant version of Parse’s system, meaning that every application being migrated will require a separate installation of the server. There is also no web based dashboard to manage the server, like the one offered by Parse. Accella typically took the optional step of creating a custom dashboard for a Parse mBaaS application to improve the client’s user interaction while managing a system. Now this step will be required.
Second, the code being offered is not totally stable – a recent update changed the startup file architecture drastically. I had made several changes to the startup js files as directed by Parse to activate file storage on S3 and push notifications. The new update wiped out those changes and I will have to redo them in a new place. Granted, this is not the end of the world, but if it has happened once, it can surely happen again.
In terms of migration, Parse’s own guide is built around the idea of setting up the server locally to the developer’s computer, while contacting a remote MongoDB instance that is prepped for production. Once the local instance is functional, the code should then be packaged and deployed to a node.js PaaS system as a single zip file. Parse does have scripts for several systems to ease the deployment process, but in this sort of deployment, it is essential the debugging be done locally until the production code is fully ready.
The approach we used in our pilot was to set up an Ubuntu 14.14 instance as a development server. [There are many services offering this, and we chose Amazon Web Services]. If you decide to start from scratch like we did, then once the instance is up and running, the following prerequisites will need to be satisfied on that instance:
- A non-root sudo user
- Node.js 5.6.x (Installation)
- MongoDB 3.0.x (Installation)
- A domain name pointing at the server
- A Parse App to be migrated
[Note the “domain name pointing at the server” item – you need this in order to create an SSL certificate to secure traffic from the mobile app to the server. You will need to own a domain name in order to create an SSL certificate signed by a certificate authority.]
Once prerequisites were satisfied, we followed a migration script written by Digital Ocean:
This migration script demonstrates all the steps needed up to the point of moving the data for your Parse app. The last step in the script is to “finalize” the data transfer. Do not finalize your data migration until you are sure all of your app is running on your new server, because, finalizing will disconnect your data on the Parse server and your mobile app will be required to use your new database.
Instead, allow the Parse system to migrate the data and then select the option to “Stop the migration”. This will tell Parse to resume servicing app requests, and your production users will remain able to work with Parse until the new server is fully tested.
To move our cloud code, we relied on Parse’s own guide:
https://github.com/ParsePlatform/parse-server/wiki/Migrating-an-Existing-Parse-App
Moving the cloud code presented further issues because the open source server does not support background jobs and expects relative include paths to be altered. Parse’s suggested solution to the background job issue is to set up cron tasks, which will certainly work but more development will be required.
On the mobile app side, the only steps are to 1) update to the latest SDK and then 2) alter the call to:
[Parse initializeWithConfiguration:[ParseClientConfiguration configurationWithBlock:^(id<ParseMutableClientConfiguration> configuration) {
configuration.applicationId = @"YOUR_APP_ID";
configuration.clientKey = @"YOUR_CLIENT_KEY";
configuration.server = @"http://localhost:1337/parse";
}]];
Be sure to substitute your app key values. Once this change is made, the mobile app will communicate with the open source parse-server. No other changes needed to be made application side.
To summarize:
- Parse is making this code available to the community – a great gesture that, for the moment, is supporting efforts.
- The open source server is not ready for production. As you read through the posts and comments in GitHub, most ports are not effortless and cloud code cannot always be used without modification.
- A developer can spend as much time porting a Parse app to open source parse-server as migrating to a different mBaaS.
- Once a port to parse-server is done, there is no longer a company managing (not to mention debugging and enhancing) the server for you.
Accella’s Advice:
At the moment, the open source Parse server is still maturing and it’s unclear if any development community will take up the care and feeding of that system once the Parse folks move on to their new jobs.
If an application is not on a time-critical development path, a good option could be using the open source Parse system as a platform to build an mBaaS that is independent of any “Parse-like” company (that could be around “tomorrow”…or not). However, if a mobile application is already in production, migrating to another mBaaS that is already at production quality is likely the better option.
