JavaScript for Line of Business Applications

I obviously chose Sails.js, I decided to use Angular because I wanted to learn it, and I used Mongo because I wanted to work with a NoSQL db (for no other reason than to learn it). This kept my stack completely Javascript, and really fun to learn. When it came time to write my models I decided to use Mongoose instead of Waterline, which involved some fun little hacks here and there to get it wired up inside of Sails. However, the real challenge came when I decided to start doing Unit Testing and TDD, and that's what I'll go in to (finally, right?). For the sake of clarity I'm going to focus on how I got Mockgoose to work with my tests 

Nowadays, with any Web app you build, you have dozens of architectural decisions to make. And you want to make the right ones: You want to use technologies that allow for rapid development, constant iteration, maximal efficiency, speed, robustness and more. You want to be lean and you want to be agile. You want to use technologies that will help you succeed in the short and long term. And those technologies are not always easy to pick out.

In my experience, full-stack JavaScript hits all the marks. You’ve probably seen it around; perhaps you’ve considered its usefulness and even debated it with friends. But have you tried it yourself? In this post, I’ll give you an overview of why full-stack JavaScript might be right for you and how it works its magic.