My First Experience With An All Javascript Project: Angular, NodeJS, and Mongo

I recently wrapped up a 9 month web application project using NodeJS and MongoDB for a backend and Angular Material on the front end.  I had a little Angular experience before, but many of the other technologies on the project were new to me.  It is quite an interesting experience taking on a lot of new technologies at once.  It can be kinda frustrating at first, but overall it was a fun project and I'm glad to have worked on it.  Anyway, I thought it would be a good time to share some of my thoughts about the technologies we used.

MongoDB

One of the most controversial decisions for this project was the use of MongoDB.  The company the project was created for has a long history with Oracle databases.  Some people have a vested interested in continuing that tradition.  However, I was tasked right at the beginning of the project to justify the use of Mongo.

It is quite easy to find articles on the internet about all the reasons that you should never ever use Mongo for basically anything period.  These articles can be kind of scary for some people, and if you have personal reasons to not want to use Mongo it is quite easy to point to these types of articles and say "see, I told you so."

Unfortunately, you can easily find negative articles like this about any technology you can name.  Whatever it is, somebody out there hates it enough to write an article about how it is inherently bad and deserves to be shunned by everyone.  This has been the case ever since the famous "Goto Statement Considered Harmful" article published before most of us were born.

Suffice to say that in the end Mongo was not in the least harmful to our project.  On the contrary, it was a key in allowing us to get a lot of functionality out the door in what was record time for the company in question.  Almost nobody thought we could do what we did, and I credit a big part of it to the flexibility of MongoDB.

MongoDB was a great fit for a NodeJS project, but also it allowed us to evolve our database in an agile fashion rather than designing it all upfront with ER diagrams and without a single argument over column naming standards.  It was a breath of fresh air compared to many other projects I have worked on.

NodeJS

Some of my feelings about NodeJS are summed up pretty nicely by Gavin Vickery, although I'm not sure about his conclusion that Python is a better solution.  I don't have a lot of Python experience.  Although I keep hearing about how Python is so popular, currently the 4th most popular language behind Java, C, and C++, according to the TIOBE index, while Javascript sits at 8, if I search for jobs in my area for each of these languages, there are a lot more javascript jobs that Python.  And there are significantly more NodeJS jobs than Flask jobs.  So, while some developers are confortable sticking with their little niche technologies, I am concerned a lot more about job security and marketability.

Anyway, the biggest problem I had with NodeJS is "callback hell".  This is the term often used for the difficulty in thinking in terms of asychronous code in Javascript.  I found that people have so much trouble thinking in these terms and getting the code right that they tend to look for ways to get around the problem rather than learn to do it the right way.

An example of somebody trying to get around doing callbacks the right way is a project on github called deasync.  The original author of deasync says on github that it is "...just a hack and I'd strongly recommend not to use it for anything."  The deasync project relies on C++ code that can cause strange errors depending upon the OS and version of NodeJS.

Another example is a project called node-fibers.  I thought at first that node-fibers seems like a more elegant approach than deasync, but it solves a slightly different problem, and it also relies on C++ code to do its magic.

I think it is better to stick with the standard Javascript way of doing things than to try to hack a solution with C++ code which could easily become invalid with some new version of NodeJS.  However, that really means you should bite the bullet and deal with "callback hell" until some future version of Javascript solves the problem.

Alternatively, if you do not like asynchronous Javascript, write your backend using another language such as Java or Python.

Restify

We decided to use Restify on this project rather than Express.  I don't have much to say about it other than it is pretty easy to use and worked fine for our project.

AngularJS

When we started our project, Angular 2 was still in beta, so we stuck with Angular 1.  The biggest problem we had with Angular was performance problems around digest cycles.  This has to do with two way binding from browser DOM to and from the model.  For sample/toy applications that you see in typical tutorials you won't run into any problems, but as an application grows the computation of keeping the DOM and model in sync can become a significant bottleneck.

Angular 2 tries to improve performance, but on future projects we are considering React instead of Angular.

Angular Material

The decision to use Google's material design had it's pros and cons.  Of course, in the future if we go with React we can no longer use Angular Material, but we can still use material design with some other library.  Angular Material was fairly limiting.  It didn't always behave as one might expect.  More often as not this is because the Material Design spec itself is so limiting.  So, we ended up supplementing with jquery controls.  For example, we did not use the Angular Material calendar but the one from jquery-ui wrapped in our own Angular directive.

The Material Design look and feel was originally crafted for Android devices, and it feels a bit strange elsewhere.  It doesn't look anything like the native look and feel you would expect on any given OS, and a lot of business users will not be content with the limited selection of controls it provides.  I don't think I would use it on my own personal projects.