The switch to Node, Express,and MongoDB: Goodbye

When I got the email last January notifying us that would be shutting down, I like many other developers were rendered speechless.  it was of course a blow to me and though I only had 2 applications that were live in the store at the time with parse as the backend I began to panic a bit. I know we were told that it wouldn't shut down until  January 2017 but I decided I was not going to wait. I had to find something new and find it now. Preferably that day. 

Inside our team of 2 people we had no one who had any experience with backend development. None. Parse made things so easy when trying to pitch a project that needed a backend to stand up a prototype in a seriously short amount of time. I wanted to find something as easy and preferably as free so I fired up google and went to work searching for our next backend provider 


Here are the options we considered.  

The open source parse server was my choice for a time, deploying it first on Heroku and then later on a Linode instance.  It worked great and once the Parse dashboard was released it seemed like an easy choice.  Why didn't we choose it then?  Well, its complicated but comes down to the simple fact that we didn't like feeling like we were tied to what we had used in the past.  I wouldn't blame anyone for wanting to use it but we had to learn something new so why not learn something fun and more full featured. So on to the next option.

Finding an easy and nearly free version of a service like Parse was relatively easy. . The closest and probably best option of the paid services is Firebase.  The problem?  I hate the nested JSON structure of Firebase.  Sure, it has a ton of great features that make it almost worth dealing with this crazy structure but almost was not enough.  It also made us feel uneasy that we would be again dependent on something that someone else hosted.  What happens when they shut down Firebase? I don't want to do this search again so these paid backend as a service companies are out. 

The LAMP stack.  Its dependable, highly used, tons of information out there but it is also so boring.  I know boring is usually a good thing when it comes to your backend so we gave it a shot.  We made quick progress with some apps using the stack and the apps were quickly migrated to use this as the backend.  They are still using them at the time of this post.  So is this where we landed?  Nope.  There are so many things I didn't like about it that the search continued.  Mostly,  I don't like administering Apache, I don't know PHP, and I didn't like mysql.  Thats the whole stack so we decided to move on. 

The MEAN Stack.  Now this one caught my attention.  In fact it seemed like such a good fit for us that we gave it a shot only a month after the parse email.  We setup an instance of the mean stack on linode and followed the directions from the site.   After installation I sat back to learn all about the route handling of express, the npm package manager, and mongoDB.  I was lost.  Hopelessly lost.  The installation I followed had installed so much boilerplate code that I had no clue where to start.  I gave up.  It took me another 3 months of looking for alternatives before I gave it another shot.  This time I started from scratch.  No express init or boilerplate code and guess what...It was so much better then I anticipated.  It was clear, concise, and easy to follow the logic of the routes and middleware. 

Our next steps were to use this to stand up our REST API for our next app.  So we started and were so happy with it that the search for us was over.  

We never got to Ruby on Rails even though I know many of the developers that I respect use and love it for backend development.  Going forward The MEAN stack is our backend of choice.  For us it is more of a MEN stack since we are not using Angular.  Our template engine of choice for now is EJS despite having relative success with PUG.  EJS for us is just much more friendly for a couple of people who don't mind writing HTML,  CSS, and Javascript. In a future post we will go into the middleware we use to handle our various needsw