Drop me a DM, and let's chat! :)
It became a tradition for me in the past two years to write recommendations for the next year on how one can become a better Node.js developer. This year is no exception! 🤗
If you are interested in my past new years’ recommendations, you can read them on the RisingStack blog:
Without further ado, let’s take a look at all the advice for 2018!
With the release of Node.js 8,
async functions became generally available. You can replace callbacks and write synchronously looking asynchronous code with their help.
But what are async functions? Let’s take a look at a recap of the Node.js Async Function Best Practices article:
async functions let you write
Promise-based code as if it were synchronous. Once you define a function using the
async keyword, you can use the
await keyword within the function’s body. When the
async function is called, it returns with a
Promise. When the
async function returns a value, the
Promise gets fulfilled, if the
async function throws an error, it gets rejected.
await keyword can be used to wait for a
Promise to be resolved and return the fulfilled value. If the value passed to the
await keyword is not a Promise, it converts the value to a resolved
If you’d like to master async functions, I recommend checking out the following resources:
When you deploy a new version of your application, the old must be replaced. The process manager you are using (no matter if it is Heroku, Kubernetes, supervisor or anything else) will first send a
SIGTERM signal to the application to let it know, that it is going to be killed. Once it gets this signal, it should stop accepting new requests, finish all the ongoing requests, and clean up the resources it used. Resources may include database connections or file locks.
Adopting a style guide across a company of hundreds of developers can be quite challenging - to get everyone to agree to the same set of rules is almost an impossible challenge to solve.
To state the (probably) unpopular opinion: you will never get hundreds of developers to agree to the same set of rules, even if it has the obvious advantage to enable developers to easily move between projects, without going the extra mile to get used to a new (even if only a slightly different) style of writing code.
If you are working in such environment, I find it the best approach to trust a seasoned developer, who will have the final saying of what makes its way into the style guide, and what does not, with the help of all the others involved. It does not matter what they come up with (let’s not start the semicolon wars), till they can get everyone to follow the same set of rules. There has to be a decision made at some point.
We see more and more companies end up on haveibeenpwned - I bet you don’t want to be the next one. When you ship a new piece of code to your customers, code reviews should involve people with security expertise. If you don’t have that in-house, or they are super busy, a great way to solve this is to work with a company like Lift Security.
You, as a developer should always try to keep your security knowledge in the best shape, too. For that purpose, I recommend reading the following resources:
Another great way to become a better developer, and become better at expressing yourself is to speak at meetups and conferences. If you’ve never done that before, I’d recommend first to speak at a local meetup, then applying to national or international conferences.
I realize that public speaking can be tough - when I was preparing for my first talk ever, Speaking.io helped a lot, I recommend checking that site out! Also, if you are just preparing to your give your first talk, and would love some feedback, just hit me up on Twitter, and let’s chat. I’d love to help out! 🤗
Once you have the topic you’d like to talk about at a conference, check out the Web conferences 2018 collection on GitHub for CFPs, it rocks!
The Twelve-Factor application manifesto describes best practices on how web applications should be written, and it was on my list for this year as well.
With the rising adoption of Kuberentes and other orchestration engines, adhering to the twelve-factor application principles are getting more and more important. They cover the following areas:
- One codebase tracked in revision control, many deploys
- Explicitly declare and isolate dependencies
- Store config in the environment
- Treat backing services as attached resources
- Strictly separate build and run stages
- Execute the app as one or more stateless processes
- Export services via port binding
- Scale out via the process model
- Maximize robustness with fast startup and graceful shutdown
- Keep development, staging, and production as similar as possible
- Treat logs as event streams
- Run admin/management tasks as one-off processes
Some of the new ECMAScript features can boost your productivity a lot. They enable you to write more self-explanatory code. Some of my personal favorites (well, they are not that new, to be honest):
If you’d like to get a full picture of new ECMAScript features, I recommend reading the book ES6 & Beyond.
What would you add to the list? Please let me know in the comments. ☺️