The Learning Process (Begins)

First things first we have to look at what Parse offers for migration. For anyone who wants to see the “Moving-On” article from Parse here is a link: http://blog.parse.com/announcements/moving-on/

Parse offerings to assist migration

• Parse is offering a database migration tool (Migrate data to MongoDB)
• Parse is open sourcing that Parse Serve (This will let you run most of the Parse API from you own Node.js server)
• There is an assumption that developers will move to Heroku or MongoLab
• Cloud code will break because there are Native Cloud Code modules that will not be available on Parse Server. (App Links, Buffer, Mailgun, etc…)
• Analytics, Jobs, and Push Notifications are no longer supported
• The Parse Dashboard is no longer available

Ok, So there is a lot more information, please check out the link above.

Not being very familiar with the plethora of services that AWS offers, first thing we wanted to know was… 

How does Parse map to AWS in terms of services?

After a quick and cursory research phase, here’s what we came up with:

 

Mind you that this is a 1000 ft view and a most simplistic mapping. Each of these services have their own set of features that are very different from their counterparts. However, a quick look confirmed that all of Calorious‘ use cases were potentially being met by AWS.

This provided us with the sanity check we needed before delving deeper into migration steps.

 

 

 

 

In addition, the AWS Mobile Hub was key to getting the basic pipeline for our application laid out with the services connected. If you have not had a look at Amazon’s mobile hub yet, it allows you to simply put together, test, and monitor mobile applications through a user friendly web interface. It also streamlines the service configurations of your application. Check it out here: https://aws.amazon.com/mobile/ A member of the Calorious team was able to see the Mobile Hub in action at the AWS Loft in SoHo late 2015.

Note* – At the time of writing this blog, mobile hub does not give you an option to have DynamoDB pre-configured in your starter app.

So now that we have shell applications that we can use to migrate our client side application code to it is time to jump into the nitty gritty.

Cognito

What do we do about users and identification? If you got your starter application from the mobile hub, chances are that you picked Cognito as one of the services. This means the starter is already set up with the pipelines for user authentication. In order to migrate successfully, we’d need to associate parse userid with amazon’s Cognito id. Stay tuned to see how we’ll achieve this. More info on Cognito – https://aws.amazon.com/cognito/

Storage

DynamoDB

When looking through the AWS documentation, you will notice that Amazon offers file storage (S3) , a hosted relational database solution (), and a hosted nosql database solution (DynamoDB). DynamoDB caught our eye. Calorious is a small startup but we have big dreams and we need something that will be able to grow with us. DynamoDB seems to fit the bill. https://aws.amazon.com/dynamodb/

DynamoDB is different from MongoDB. DynamoDB encourages you to think about your data as key-value pair. Needless to say you have to examine the way your applications data is laid out in Parse and restructure your database in DynamoDB. Parse leverages the use of pointer  and relation objects that allow you to create a relationship between objects. That concept goes out the window when working with DynamoDB. THATS OK. As we learn and re-design our own data, we will explain our moves and mistakes during data migration. 

Lambda

Last but not least, AWS lambdas provide the ability to invoke your functions via events. It is like Parse cloudcode on steroids. You can connect your functions to pretty much any of the aws services and invoke it to perform various things. Alright we are pumped to get started! so lets do this…