Parse to AWS - the Migration

We used Parse.com for a simple integration with Facebook login, and to manage users on a project. Parse was well documented and easy to work with. The integration took about a day, which was surely faster than managing our user accounts or writing our own Facebook authentication. The next week, Parse makes its announcement, which of course gave us some things to think about.

While our Parse usage was small and we had a few weeks before the data went lights-out, what would it take to transfer the service? The intent of this exercise is to determine what is needed and the steps necessary to transfer from real-Parse to an in-house version. The article by AWS made it seem easy, so I'll write here the things I found while reading there.

Server Setup

Planting Beans

AWS made it simple to create a new parse-server-example, with a one-click button to start a new application on their ElasticBeanstalk service. From start to finish it was about 4 clicks, but still really simple.

Note: You need AWS Policy access for this link to work. I added "ElasticBeanstalkFullAccess" to my IAM role group. Otherwise the link doesn't go anywhere useful, which you'll know because you can't select any options on the Beanstalk home screen.

Get Some Mongo

For Parse to work, you need a Mongo database (version 2.6.x or 3.0.x). You could roll your own on AWS, but having someone else do it for you is faster. We went the MongoLabs route for their free-tier. Signup and setup were as easy as expected.

Application Integration

And that about wraps up the AWS How-To. Now that we have a server, everything works right?

Well, not quite. Our app has three components that connect to Parse.com. A NodeJS server (that makes HTTP requests), a javascript web client and a Xamarin client (namely for iOS). Some things need to be addressed: urls and keys.

URLs

Most client SDKs point to "parse.com" or maybe "api.parse.com". How do we point these compiled client libraries to our new server?

Turns out, answers were at the bottom of the parse-server-example readme. There are values in the SDK libraries that allow the URL to be changed, and basically the key is not used on the self hosted parse server.

For our javascript SDK, which was running on SSL, putting in a non-secure URL didn't work, giving a good error like:

Mixed Content: The page at 'https://localhost:5010/game.html#/landing' was loaded over HTTPS, but requested an insecure XMLHttpRequest endpoint 'http://parseserver-xxxxx-env.us-east-1.elasticbeanstalk.com/parse/login'. This request has been blocked; the content must be served over HTTPS.

To turn on SSL on the beanstalk server, you need a certificate. AWS Certificate Manager can help sort those, and the Load Balancer configuration in the Beanstalk console can turn on port 443 listening using one of your valid certificates. 

Keys

The client applications are given keys by parse, typically for their own specific SDK. The "javascript key" allows javascript access on our web client, the "REST key" allows HTTP access using our server client, and same for Xamarin. How are those included in the Elastic Beanstalk instance, when the only environment variable is for the "Master Key"?

Also, the Facebook app ids need to live on the server somehow.

In the parse-server readme, there is the option to use environment variables which could be configured via the Beanstalk console. Whether the AWS server example respects them when the instances refresh remains to be seen.

Wrap Up

I'm stopping this investigation at the certificate chain since we don't have a wildcard cert, and SSL is needed in our app (so mixing non-SSL isn't an option for me). It would be possible to keep going, and I think the entire parse server would function as a drop in replacement with minimal code changes, but I'll have to revisit this at another time to completely integrate to our existing app.