Theseus also went back from (callback) hell At we recently rewrote our entire api codebase, migrating from a standard node-express api to a brand-new typescript app. This was quite a challenge, and it took quite some time so the choice of doing so was not obvious to make at the time. Hunteed Now that we’re done with it, we think the benefits of doing so are tremendous. Here’s why. TL;DR It’s more robust It’s easier, faster to understand/maintain It’s 25% fewer lines of code No more callback-hell Typescript learning curve: very low What we started with (a.k.a. why bother ?) We started with a node-express app, originally bootstraped with a popular yeoman build. javascript The code was es6-written, and some perplexing babel config was somehow making things work, though I wasn’t so sure why and how. We also ignored the big red flag saying that babel should be used in production (but was it really?). not The app code coverage was good. However, testing new features required a lot of boilerplate and intricated callbacks before you could actually write a test. This was a real trouble, as the temptation to write untested code only would only grow. I’ve come to think that using a lot of mongoose hooks made the code a bit difficult to understand. First it looked nice and efficient, but at some point it was not obvious to see what happened when you called a method. Things could be more explicit. A lot of callbacks. Callbacks everywhere. It did not felt like such an issue at the time, as we got quite accustomed to use them. You’ll see how we changed our minds about that :) Why typescript ? 1. Obvious advantages of typings Typing your code adds a lot of robustness to your project. This has been discussed a lot elsewhere, but some main advantages could still be mentioned here: : Some people say if you have functions that take many arguments, then at some point, someone reverse them. Calling instead of is now impossible. Typescript checks the input/outputs so you won’t commit such a mistake. Consistency will f(foo, bar) f(bar, foo : in typescript2, you can check null errors at compile time: Null error checking : The compiler knows what the input/output types of your functions are. I/O types checking Note that will produce an array of numbers . The compiler is able to figure it out by itself. [1, 2, 3, 4].map(x => add(x, 1)) [2, 3, 4, 5] 2. Await is the new callback One of the typescript features I like the most is the ES7-like . Although this is currently an ES7 proposal, typescript already supports it, and it knows how to transpile to ES6 code (by taking advantage of the ES6 iterators, but you don’t have to worry about that as a dev). async/await await [edit]: since typescript 2.1, you can transpile [_await_](http://react-etc.net/entry/async-await-support-for-es5-browsers-pushed-to-typescript-2-1) to es2015 \o/ covers the details about . Long story short, as long as a function is declared as it will return a Promise. Moreover, it will allow to use wich tells the compiler to wait for a promise to resolve, without blocking the thread. For instance, This post async/await async, await, This is non blocking, although it looks like regular synchronous code we all dream of This allowed us to change some code that looked like our old, tedious, cb syntax to the now fancy new await syntax ConclusionGetting rid of the tedious callback/callback error handling process allowed us a reduction of 25% of the codebase ! Want to “promisify” a function of yours ? easy as pie: 3. Fancy tests We used to have a lot of callbacks/promises in our tests. As a result, it became more and more difficult to even properly initialize a test. Having a testing environment that is tedious to work with is a catastrophic thing. At some point, someone will skip testing, because it is too much of a hassle. With the awesome lib and functions, testing a route has now become quite elegant: supertest-as-promised async Look ma, no callbacks ! Yeaaah, but how do I deploy ? Same as usual, except that you should transpile your code before uploading it. If you choose to use , be aware that you need to transpile to at least ES6. So you will need to run a recent enough version of . Most of the modern tools do (like heroku, modulus…), and it should not be an issue for backend-api deployment. await nodejs At we open-sourced (checkout for more details) that you can use. The workflow can be summarized as: Hunteed a build this story write typescript code saving file triggers a code transpilation that outputs new js in /dist changing the js files triggers a test run. Note that the tests are actually run against the transpiled javascript files. Which is good, since the transpiled javascript will actually be run in prod. Of course, map files allow to link the errors to your typescript files. Once your directory is transpiled and tested, it is simply a good old ES6 node-express app, that you can safely send to prod. Obviously this is a CI-server work. You could, but you won’t do that from your computer. dist How about the learning curve ? In my opinion, getting to code in typescript takes less than a day for an experienced javascript developer. Changing your to is already enough to benefit from the ts compiler awesomeness. If you feel brave enough, then you can turn on the compiler options, that will ensure that no variable is left undeclared function (user) {...} function (user: User) {...} noImplicitAny It was not so obvious, however, to understand how to import typings from external libraries. With typescript 2 it’s more easy, since most of the time you simply have to install from npm registery in order to make things work. @types/something All things considered, though, it was very fast and it took less than a week before we noticed how fast and secure it feels to code with typescript. Conclusion Benefits we observed about working in a typescript environment: made me change my mind about javascript. We now have something that looks that a good programming language, with concurrency support. await/async Adding tests is easier than before. It is now tremendously easy to refactor something. Want to change the signature of a function ? simply rewrite and see the compiler tell you about every line of code that should be adapted. When the compiler’s finally happy, so are you, because it probably works. The code is easier to understand. Functions are signed in their definitions, and interface make it really easy to know what methods/attributes are available on any object. Bonus: if you mess it up anyway, then the compiler will warn you. thanks to everyone who are responsible for this typescript awesomeness. You guys rule. Many Feel free to share some feedback about your ts transition if you have some ! Related links: Edge node-express api using Docker, Typescript, codeship & mongoose How we happily dockerized our development environment

Heroku

Microsoft

Too Long; Didn't Read

Making security fun one episode at a time

From callback swamp to typescript heaven: why we rewrote our entire api in typescript

Too Long; Didn't Read

Companies Mentioned

Aurélien Hervé

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

From callback swamp to typescript heaven: why we rewrote our entire api in typescript

Too Long; Didn't Read

Companies Mentioned

Aurélien Hervé

About Author

TOPICS

THIS ARTICLE WAS FEATURED IN...

RELATED STORIES