# Typescript Back to Front  —  First Impressions

When I was looking for a cool starter kit / seed / boilerplate or whatever you want to call it for the MEAN stack fully written in typescript, I found nothing really useful. So I started to create this seed myself. Here are my first impressions on this stack. The current result is hosted on github, free to use and reuse!
The MEAN stack was “a thing” once, but it got abandoned over time with Angular2+ coming along, rendering the old projects a bit overhauled. But why would anyone want to use the MEAN stack in the first place? For me, there has always been one big advantage with this stack: Only one language in the project. Now with the rise of Angular 2, this brings a bit of a mixup into the MEAN world. Most backend libraries for the Mongo-Express-Node part are written in Javascript, while most Angular 2 things are written in typescript. If we still want to have one language everywhere, we need to decide: Frontend Angular 2 in JS or backend in TS. Since I love typescript, for me the choice was easy. Typescript everywhere it was!

### M — Mongo

I started out with the backend, since this had much more unknown factors for me. Using Angular 2 you’re backed by a lot of tutorials and Google supporting the framework, but with a TS Mongo-Express-Node backend, you’re a bit on your own. The questions I had were along the lines of “what is the tooling like?”, “can I run my unit tests with IntelliJ like I’m used to from JUnit?”, “for how many npm packages are there typings?” and “how reliable are those packages?”.
I started with the database layer, for which I found a Mongo Connector with typings. For unit tests I decided to go with Mocha and Chai. I placed the test files in the same directory as the source files and was able to run them from the command line like:

mocha --reporter spec --compilers ts:ts-node/register '**/*.test.ts

Of course, when project gets bigger you want to be able to run individual unit tests. This is possible with grep , which is somewhat cumbersome. However, after some hours I managed to get IntelliJ to run individual unit tests directly from the editor. Since then the development experience has improved drastically.
During the development of the database layer, I didn’t run into any major problems. I’m not the biggest advocate of MongoDB by the way, but the MEAN stack was an existing “brand” I could build upon. In any case, I would prefer an SQL database for any real web projects based my past experiences with Mongo. Here are my reasons why. In case you share this view, I also abused the “M” in MEAN to create a MySQL branch of the stack. I designed the database access interface in a way, such that the rest of the application doesn’t need to know whether it’s Mongo or MySQL backed. Modular design ftw. In any case, I’m going to maintain both branches in the future.

### A — Angular

For the frontend itself, originally I didn’t plan to do anything, since it’s mainly the backend that was lacking typescript boilerplate, while Angular 2 has a nice CLI for scaffolding. But then I though, “well, you should at least demonstrate how your cool backend api is used”. And I set out to create a small frontend. I have to say I really love to work with the CLI since I’m a person who generates quite small components (“one for every button”) and this just makes it a whole lot easier. I had my shell scripts in Angular 1 that did this for me, but with the AngularCli it’s an even neater experience. Also, when it comes to bundling a production build it’s unbeatable. Simply being able to run ng build –prod is just amazing. I like Angular2 a lot in general. The only thing that I’m still not 100% happy with is the state management since everyone does it a bit differently and there aren’t really any best practices, but apart from that, there’s not so much I found to nag about so far. Well , there are a few pitfalls, but mostly stuff works as I’d expect it to do.

### N — Node

Finally, having strapped all of those things together, a functional REST-API and a simplistic frontend I decided to host a demo of the app. It’s still constantly improving as I’m working on the project, but that’s what it is now. For deployment I chose to, again, completely separate the backend and the frontend. The frontend just consumes the backend through http://demo.tsmean.com:4242 . I think that’s a pretty cool setup, since like this you can also use the remote backend to locally develop your frontend. For example if you’re only interested in the frontend, go ahead and get the git repo of the frontend and use that REST Api to test against! The backend has to allow CORS requests that this setup works, but apart from that nothing had to be configured. The frontend itself is served by a 20-line node script (also using express).

## Conclusion

I’m currently working on improving the modularity of the system, so there’s really a mysql and a mongo module, and also authentication etc. is modularized. I’m doing this using typescript npm libraries, on which I’ve written a small tutorial how to build them trough the process at how-to-write-a-typescript-library.com.