Learning Web Dev Series – Part 7: Parse shutting down

Posted by Gjermund Bjaanes on February 21, 2016

For my Extreme Results project, I have used Parse as my Backend-as-a-Service (BaaS).

When they recently announced that they were shutting down I was quite disappointed.

Annoying to have a big part of your application pulled from underneath you.

 

Rip Parse

 

The choices

When this happened I basically had three options:

  1. Host my own Parse server
  2. Switch to another BaaS
  3. Create my own server from scratch

 

Option #1 Host my own Parse server

Option #1 is available because Parse has open sourced their server to allow people to migrate their existing apps. They have even create a migration guide (which I guess is nice of them).

Luckily, Extreme Results is not in production, so I didn’t have to choose this.

I didn’t really want my brand new application to have a dead backend. A backend with potentially no new updates. Option #1 just rubbed me the wrong way. It didn’t feel right.

 

Option #2 Switch to another BaaS

Option #2 would require me to rewrite all the cloud code and migrate the data model to someone else’s backend framework. Might not be too much work, but certainly more than option #1.

There would however still be to possibility that a new BaaS could shut down and leave me where I’m right now. Not ideal.

 

Option #3 Create my own server from scratch

For learning purposes, option #3 is certainly the best choice. It would require a lot more work though.

It would allow me more control of the backend, potentially allowing me to create a even better backend.

 

The choice

With the following pros and cons in mind:

 

Hosting my own Parse server

  • Pros
    • The fastest way to get up and running again
    • The “easy” choice
  • Cons
    • Dead platform
    • Would need to deploy it myself

 

Switch to another BaaS

  • Pros
    • Fast to get up and running compared to writing everything myself
    • No deployment and scaling to worry about (probably)
  • Cons
    • Might shut down at any time
    • Potentially more expensive than Parse and creating and deploying my own server

 

Create my own server from scratch

  • Pros
    • Amazing learning opportunity
    • Any functionality I can think of
    • Very flexible
    • Would never be shut down by someone else
  • Cons
    • A lot of work
    • Would need to deploy it myself
    • Would need to scale it myself

 

I chose option #3 - creating my own server from scratch.

The pro I weighted most was the possibility to learn new stuff. It was just too good an opportunity to pass on.

 

Extreme Results Server

The were a lot of choices to be made once I decided to write everything myself. Not all choices are made yet, but at least enough to get started.

Node.js Logo

The server is being written in Node.js with Express.

I wanted to do it like this, because then I could learn even more JavaScript (which is fun!). I could also leverage my experience with Jasmine for unit testing.

 

I am currently writing unit tests and integration tests for the first Outcome API’s, and it is coming along nicely. It is actually pretty quick to write Express apps once you learn the basics.

 

Pluralsight Logo

To actually learn some of this new technology I used a Pluralsight course called “RESTful Web Services with Node.js and Express” by Jonathan Mills. It teaches the basics of Express and Node with along with some unit and integration testing.

 

I am not sure how I will deploy the server for production and testing environments, but I hear Heroku might be a good fit.

The code is as always hosted on Github:

https://github.com/bjaanes/ExtremeResults-Server

 

The Journey – Visualized

I have a visual aid to help show where I am currently at on my journey. I have created a “prezi” presentation to visualize my path more clearly.

It will be updated through the course of this series – so it might be longer than the current post you are reading.

 


Follow me on Twitter: @gjermundbjaanes