Typescript Mongo Express Angular.io Node (MEAN) Boilerplate

UPDATE: A cool starter kit has developed out of my initial Typescript MEAN seed / boilerplate! It currently uses Angular4 and is from mid 2017.

 

I was a bit shocked when I searched for Typescript MEAN (Mongo-Express-Angular-Node) tutorials and boilerplate code (with Angular.io I mean Angular2 or above). There is some material, but it’s pretty outdated. Of course it’s a bit unfortunate that you have to count 2015 as outdated in 2017, but that’s how it is in the frontend world. So I set out to build my own boilerplate code for MEAN (Mongo-Express-Angular.io-Node) apps that use Typescript for many apps to come. I also wanted the boilerplate to include unit tests, so this is not something you’ll have to add later on, but can start with right away.

So basically the requirements that I had for this boilerplate were:

  • 100% typescript.
  • Good coverage with unit tests.
  • Support simple REST calls of the form api/v1/:resourceName/:resourceId

For the backend, the Mongo-Express-Node part, a lot of setup had to be done. For the frontend, thanks to AngularCli I could dive more straightforward into development and I also had more experience in developing a frontend with Angular, than a backend in typescript.

In order to being able to develop independently on the frontend and the backend, for example if you have backend devs and frontend devs on your team, I setup the basic structure of the boilerplate like this:

typescript-mongo-express-angular-node-seed
├── .git
├── backend/
│ ├── .git
│ ├── db-module
│ └── ...
└── frontend/
  ├── .git
  ├── user-module
  ├── main-module
  └── ...

At first, I only had a git-repo for the backend, one for the frontend and one that strapped both together. Much has happened since then. Now each module has it’s own repo, run it’s tests independently and can be developed without needing all modules. For me this change in workflow was hugely satisfactory. Instead of a monolithic app, now I have many small maintainable modules, that together make a solid well tested application. Each module also has it’s own npm package (all scoped under @tsmean) and if one module requires another, it is loaded as an npm module! This has upsides and downsides, for example if you have a small bug fix in one module, then you need to publish & pull again in another module. But this cost is small, since what you get is a well designed scalable architecture. I could just hire someone with no knowledge about the rest of the application to develop the user module. For this workflow it is essential to understand how to build & publish libraries, so I’ve summarised this here:

Since the starter kit / boilerplate is in constant development, I don’t cover too much specifics here. Rather try to check out the code directly at github.com/tsmean/tsmean. It might strike you as complex at first, but after getting into the fullstack typescript development with feature modules, you will never want to go back.

In the following, I also append a short “Why the MEAN stack”, because knowing the why is even more important than knowing the how.

Why the MEAN stack?

Developer experience

As opposed to backend and frontend in different languages, you’ll just need to write Typescript most of the time. This makes you a bit faster as a full-stack dev, since you don’t have to switch context that much and just need to be fluent in one language. Also, if you’ve implemented some routine in the backend, but you decide it would be better to run it in the frontend (or vice-versa), it’s much easier to migrate the code. You can share code across backend and frontend and you can use the same packaging managers. Overall, one language brings efficiency through consistency.

On the downside, with a backend in Node & Mongo, also a lot of problems can arise. Node uses the non-blocking asynchronous nature of javascript (more on that in the next section), which requires for a lot of callbacks. This makes programming harder and less linear. For example if you have java-devs in your team, they might have a hard time adjusting to this and mutter “wtf, that’s retarded” quite a few times. With the new async / await syntax introduced however, a more synchronous writing style is starting to develop, while maintaining the benefits of non-blocking.

Non-Blocking I/O

Node runs on a single thread and all it’s calls, for example to the mongodb, are asynchronous. This means that no resources are spent waiting for answers to return, which is often where most of a web-servers capacity is lost. Your classic Java server could be non-blocking, but no-one ever writes it like that, so the advantage with a node-server is that all your packages, modules, tutorials, stack overflow answers etc. will be non-blocking out of the box.

Conclusion

The Typescript MEAN (Mongo-Express-Angular-Node) stack can be the stack of choice for frontend devs going full stack. However, there doesn’t seem to be a lot of good, up-to-date and typed (typescript) boilerplate code out there for the backend part. So I set out to create & maintain this boilerplate code.  After developing for half a year with it, I’m more hooked than ever. It doesn’t make everything magically simple and you still need to learn a lot. For example if you don’t know Angular yet, that’ll be quite the journey. But you still have to learn and master less concepts, than if you were to have a frontend with some JS framework and a backend written in yet another language. Here you can find the current seed. To get the latest news, follow tsmean on Twitter. Additionally, there’s now a small homepage: tsmean.com !

Leave a Reply

Your email address will not be published.