February 28, 2022
Technical Principles and other Adventures in Nodeland - Issue #49
Hi Everyone, this edition is bittersweet. It’s packed with all the usual OSS releases and news that you got to enjoy, however the current world situation keeps me awake at night. I #StandWithUkraine.
Last week I was hosted in PodRocket, the podcast of LogRocket! We talked about Fastify, Pino and community building!
Matteo Collina is Chief Software Architect at NearForm, a member of the Node.js Technical Steering Committee, and the creator of Fastify and Pino. In this episode, we talk about making Node applications faster, Fastify v4, ORMs, npm downloads, and much more.
|
Early this week a colleague asked me what principles I followed when designing architectures. Here is my list:
1. Conway’s Law is paramount.
In order to design a piece of software we need to “design” the team that is going to produce it.
2. Developer Experience is key to productivity
Developers must spend as much time in the “flow” state to maximize the joy their profession sparks. A developer in flow state can resolve any problem in front of them. Meetings and constant interruptions break them out of the “flow”, impacting their job satisfaction and productivity. Given that coordination overhead (= meetings) increases quadratically with the number of people in a team, developers works best when in teams of 4-6 people.
Optimising developer productivity is a fundamental activity of every team. Every tool and framework could impact developer productivity. Choose wisely.
3. DORA metrics, not burndown charts
Scrum and other Agile methodologies predicates the use of story points and time to assess how much work will fit in a sprint. Then, the team is benchmarked with these estimates. This incentives writing low quality software as bug fixes will be more story point to churn later on.
Continuous Deployment is the way. The best way to measure CD are DORA metrics:
- deployment frequency (DF)
- lead time for changes (LT)
- mean time to recovery (MTTR)
- change failure rate (CFR)
I’m so excited about Node.js v17.6.0 as it’s the first one to ship HTTPs import of modules behind a flag. We are still early days of this new method of module installation.
Node.js® is a JavaScript runtime built on Chrome’s V8 JavaScript engine.
|
The Fastify community worked on a couple of module updates: fastify-cookie and fastify-swagger, to fix a few minor bugs.
|
A Fastify plugin to add cookies support. Contribute to fastify/fastify-cookie development by creating an account on GitHub.
|
|
A Fastify plugin to add cookies support. Contribute to fastify/fastify-cookie development by creating an account on GitHub.
|
|
Swagger documentation generator for Fastify. Contribute to fastify/fastify-swagger development by creating an account on GitHub.
|
|
Swagger documentation generator for Fastify. Contribute to fastify/fastify-swagger development by creating an account on GitHub.
|
We will be soon starting to migrate all fastify-* modules that are maintained by the Fastify team to the @fastify namespace. The goal is to make them immediately recnognizable. You can read about the progress at:
|
Prerequisites I have written a descriptive issue title I have searched existing issues to ensure the issue has not already been raised Issue If we are going to deprecate fastify-* modules, as outlined in #3482 (comment), then I really ne…
|
|
Prerequisites I have written a descriptive issue title I have searched existing issues to ensure the issue has not already been raised Issue If we are going to deprecate fastify-* modules, as outlined in #3482 (comment), then I really ne…
|
Mercurius shipped an important update that updates graphql-jit so that v9 works with typescript. Thanks to Simen Bekkis it got resolved quickly. Read up on the following issues:
|
Implement GraphQL servers and gateways with Fastify - Release v9.3.3 · mercurius-js/mercurius
|
|
Implement GraphQL servers and gateways with Fastify - Release v9.3.3 · mercurius-js/mercurius
|
|
This resolves a peer dependency warning for graphql@16.
(I realise it’s in semver range, but forcing the update so the dependency tree is guaranteed to be valid also after aggressive deduplication makes sense)
|
|
This resolves a peer dependency warning for graphql@16.
(I realise it’s in semver range, but forcing the update so the dependency tree is guaranteed to be valid also after aggressive deduplication makes sense)
|
The other fix mercurius v9.3.3 shipped is a fix for the gateway to support GraphQL fragments in certain queries:
|
The federated node was not receiving the Fragment declaration from the gateway, so it was triggering an Unknown fragment error
|
|
The federated node was not receiving the Fragment declaration from the gateway, so it was triggering an Unknown fragment error
|
Last but not least we had a new release of mercurius cache:
|
Contribute to mercurius-js/cache development by creating an account on GitHub.
|
|
Contribute to mercurius-js/cache development by creating an account on GitHub.
|
We fixed a bad bug (in fact, a typo) that could lead to crashes or data corruption in case of multi-byte utf characters. I’d like to thank the issue reporter that created an easy way to reproduce the problem, thanks https://github.com/petru-planable!
|
|
|
|
|
|
|
A streaming way to send data to a Node.js Worker Thread - Release v0.13.2 · pinojs/thread-stream
|
|
A streaming way to send data to a Node.js Worker Thread - Release v0.13.2 · pinojs/thread-stream
|
Could package-lock.json be an attack vector? Indeed it can. Read up at:
|
Trying to figure out how hard is it to sneak something bad into open source packages. Tagged with javascript, security, opensource, npm.
|
|
Trying to figure out how hard is it to sneak something bad into open source packages. Tagged with javascript, security, opensource, npm.
|
I’m so impressed that yelp is using techniques that James Snell, Anna Henningsen and myself, theorized and built while they were at NearForm in the last few years. I’m glad we built something of valuez
At Yelp, we use Server Side Rendering (SSR) to improve the performance of our React-based frontend pages. After a string of production incidents in early 2021, we realized our existing SSR system was failing to scale as we migrated more pages from Python-based templates to React.
|
I used and maintained several generations of HTML5 slides. I find that using git to store slides provides a better solution for technical topics, more importantly if there is a live demo. My colleague Jonas demoed slidevv… and we have been using it since!
Presentation slides for developers
|
I’m a user of Docker and I always recommended my clients to buy a subscription for Docker Hub to store their images for deployment. Recently Docker changed their licensing of Docker Desktop, making it a paid product. While I support their decision to become profitable, I had to evaluate that the price associated with Docker Desktop was worth it. Late January I had to make a decision if I should buy a license. A colleague pointed me to colima, a barebone Linux vm for Mac OS X that can be used to containers. Check it out and remember to support his maintainer!
|
Container runtimes on macOS (and Linux) with minimal setup - GitHub - abiosoft/colima: Container runtimes on macOS (and Linux) with minimal setup
|
|
Container runtimes on macOS (and Linux) with minimal setup - GitHub - abiosoft/colima: Container runtimes on macOS (and Linux) with minimal setup
|
