Blog

How to migrate Parse app to AWS – our story

Parse announced that they were going to retire on January 28, 2017. It is a big problem for all customers using Parse for their apps because they have to migrate all data and set up their own backend. We have already moved one of our apps and we want to share with you our experience.

In this article you can find:

  • general info of Parse, Parse Server and Parse Dashboard,
  • info about database migration and which option has we chosen,
  • how to set up minimal Parse Server locally,
  • info about problem with files migration,
  • why we have chosen Amazon Elastic Beanstalk and how to deploy Parse Server there,
  • how to set up and deploy Parse Dashboard.

parse_amazon_mlab

Parse introduction

Parse is a SaaS (Software as a Service) backend provider for mobile and web applications. While using it you will be able to build your application easily without the necessity of building your own backend. Out of the box you have ready features like:

  • data storage in document-oriented database,
  • files storage,
  • users password and third-party authentication (for example with Facebook),
  • push notifications,
  • Apple In-App Purchases validation,

and much more with REST api and ready iOS, Android, JavaScript and others SDKs (even for Arduino). The usage of such solution can speed up development and reduce the cost of application. All docs and SDKs are available on parse.com/docs.

Parse is going to retire on January 28, 2017 and all hosted services will be disabled. It might sound like a disaster for all existing apps although Parse team has done a great job and hasn’t left their customers on their own. The team has moved all software to open source so you are enabled to set your own instance of Parse Server and use SDKs without any need to build your custom backend. So if you have existing app you should start migrating your data and setting up server. If you want to start a new application with Parse you can also do it with Parse Server. All Parse software you can find on GitHub.

Database migration

Migration process is described very clearly in Parse Server documentation on Migrating an Existing Parse App. The first thing which you have to do is to move your database. It is very essential to do it before April 28, 2016 because it will give you more time to configure and set up server. However the most important is that Parse team will place such customers issues with higher priority. Please check What happens if I don’t migrate my data by April 28, 2016? at Parse documentation section for more info. After data migration, according to the instruction you should set your local instance of Parse Server, configure it and update all your client apps to work with the Parse Server. If everything works well you should deploy it to the production environment.

We were wondering how to update old iOS apps which were already on store and start using a new backend with the database which would be soon migrated. We were afraid, that they would stop working. According to the documentation there is no need to worry about it. Because after having the database migration completed, hosted Parse server will be running until January 28, 2017 and will be using your newly migrated database. The old apps should still be working without any problems. So you can easily migrate only database before you will start working on Parse Server and before updating client apps.

parse_migration

As you can see on picture below on the top is presented how clients like iOS app requests for data. It uses hosted Parse server which gets its from its hosted db. On the bottom we can see how looks data flow when we replace Parse Hosted DB with our own MongoDB. The old clients can still communicate with api.parse.com which gets and stores data in your own database this time. The full visualization is presented on Visual Overview in documentation.

mlab_rocket_object

Parse recommends the usage of mLab or RocketObject as your new database hosting. Both of those providers fully manage your database, so you don’t need to worry of setup. Of course if you want you can use any other solution including creation your own cluster. We have chosen mLab shared server option for our project which is the cheapest solution of $15 per month for 1GB. For our app it is enough and the advantage of mLab is that we have the choice between Amazon S3 Bucket, Microsoft Azure or Google Cloud Platform where our data will be stored. We decided to choose Amazon because our intention was to deploy there our backend as well. You can also use mLab free sandbox plan to set up there your staging version of database. Whatever you will chose for your project, follow the Migrate Parse DB to Self-Hosted MongoDB documentation to move your database.

Local Parse Server set up

The next step is to set up your local Parse server which is core of the system. It is the open source backend built on Node.js Express framework. It implements all of Parse features, but it is still under development and might have some bugs. We found some of them while we were migrating our app so please check your app carefully in local environment to make sure that everything is working correct.

parse-server-logo

You can start your application cloning Parse Server Example which have reach configuration example for almost all deployment options. It is good documented and probably it will be all what you need. However we decided to start our project from scratch and create parse server embedded in express app. To start minimal version of Parse server install parse npm package and express npm pacakge. Create yours server main file like below.

Presented configuration is enough to start server as middleware before SDK and MongoDB. There are many other configuration options which are well documented on Parse guide. To start your server run node app.js in a console. When it starts, you can test it using below curl command which creates new object.

Files migration

Parse Objects can have File fields which allows you to store files like images or pdf documents. Parse keeps files in it’s own AWS S3 Bucket and Mongo database stores only references (URLs) to them. Migrating database as described above copies only database data and files references, but not files itself. You have also to move the files to your storage before January 28, 2017 or they will be deleted. However there is problem because there is no easy solution or tool for moving files for now. The Parse team is looking for one as we can read on migration guide, but now we can only find their plan how to do it (files migration plan).

Parse Server can be configured to work with Parse S3 Bucket so it will still serve files without need to migrate them. You need to set fileKey parameter initializing ParseServer in app.js which is shown above (check parse guide for more info). The key can be found in Parse Dashboard > YOUR APP > App settings > Security & Keys. Remember that setting this key doesn’t solve the problem, but only allows you to focus on other things until the tool for files migration will be introduced.

You should also set up your own storage for any new files which you will want to add. Parse only require to provide fileAdapter property with adapter which exposes methods like: createFile, deleteFile, getFileData and getFileLocation (check files adapter base). There are build in adapters for stores like Amazon S3, Google Cloud Storage or MongoDB which you can use. Check documentation for more info.

Parse Server deployment

We considered between Amazon Elastic Beanstalk, Google App Engine and Heroku, and finally decided to use Amazon Elastic Beanstalk. Each of those solutions are PaaS (Platform as a Service). It means that we don’t need to set any software like load balancers or web server. We only deploy our code and the rest is handled by platform. However each of these differs in details what is presented in table below. Our considerations are tuned for our project which is small application with no special requirements. Each of those three solutions are quite cheap and scale easily. Amazon and Google scale automatically, increasing and decreasing number of instances depending on requests traffic, but Heroku needs to be managed. All of them support Node.js environment, but Google App Engine is in beta version.

Amazon Elastic BeanstalkGoogle App EngineHeroku
Price~$10
for t2.micro
1vCPU 1GiB
free
28 instance/day
$7
per instance
Scalingautoautomanuall
NodeJs environmentOKBETAOK

State on 4 March 2016

We decided to deploy on Amazon Elastic Beanstalk with Node.js environment.

elastic_beanstalk_and_nodejs

We need to create package.json which specifies what npm packages are needed to be installed and how to start server.

Next create Amazon application and deploy our code.

  1. Before start zip together app.js created on “Settings up local parse server” section above and just created pacakge.json.
  2. Go to Amazon Elastic Beanstalk.
  3. In the right top corner click “Create New Application”.
  4. Type application name (for example “parse-server”) and click “Next”.
  5. Next you will see “New Environment” page. Click there “Create web server” button.
  6. You should be on “Environment Type” page. You have to select “Node.js” form “Predefined configuration:” and click “Next”.
  7. On “Application Version” page set “Source:” as “Upload your own” and select zipped files. Click “Next”.
  8. On next “Environment Information” page type your “Environment name” (for example “parse-server-env”) and type “Environment URL:” which will be your server url. Check is URL available and if not type another one. If everything will be valid click “Next”.
  9. On next pages “Additional Resource”, “Configuration Details”, “Environment Tags” and “Permissions” just click next.
  10. You should land on “Review” page on which just click “Launch” and wait until you environment will be ready.
  11. Now you can access your parse dashboard using “Environment URL” which you have typed in point 8.

Parse Dashboard deployment

Parse dashboard is separate project which is also open source and you can find it on GitHub. You can just install it using npm (parse-dashboard package) and launch it from console.

Dashboard can be accessed through browser entering http://localhost:4040. If you need it only for yourself you can launch it in such way every time when you need without deploying. In our case we need it to be online and like the Parse Server we deployed it to Amazon Elastic Beanstalk, but this time as Docker container.

elastic_beanstalk_and_docker

To do this you will have to create three files: Dockerfile, parse-dashboard-config.json and Dockerrun.aws.json. Below you can see Dockerfile which is recipe for container build instructions.

It just imports parseplatform/parse-dashboard container as a base, adds configuration, exposes port 4040 and runs the server with two parameters. The first is path of configuration file and the second allows to access dashboard using http (default https is required). It is not recommended, but our server will be deployed to elastic beanstalk which is accessed by proxy. If we want we can later set Amazon to use domain with https. Next file presented below is dashboard configuration.

The first property “users” is a list of users who can access dashboard. Parse dashboard implements HTTP basic access authentication so it is the reason why https connection is recommended. The next one “apps” is the list of apps which are managed by dashboard. If we have production and staging app we can add both. The last file is Dockerrun.aws.json configuration which just tells AWS Elastic Beanstalk which docker container port is exposed.

All files should be in the same directory. Next we have to create Amazon Elastic Beanstalk environment. To do that you should repeat the same process like for Parse Server deployment described above with same changes. In step 1 zip presented files: Dockerfile, parse-dashboard-config.json and Dockerrurn.aws.json. In point 5 you should choose “Docker” environment instead of “Node.js”. The rest steps are the same. You should also set domain with https to make the dashboard secure with HTTP basic access authentication.

Summary

Migrating the Parse backend is quite easy, but it depends on application complexity. Standarized simple server can be deployed in few hours, but if you have a lot of Cloud Code you might need more time. However due to that we can develop our app more easily. We are able to set up our Parse Server locally what hasn’t been possible before. App performance should be also improved as soon as you have your own dedicated Parse instance deployed. When you set it up, maintenance will not cost much due to the fact that solutions like Amazon Elastic Beanstalk are self-managing. The only problem which has not been solved yet is the migration of files, but we do hope that it will be fixed up soon.

What do you think about the topic? Any thoughts?

Droids On Roids Pixel