December 6, 2021
Fastify@4 is approaching... and other Adventures in Nodeland - Issue #38
Hi Everyone, as you read this I’m going to take a few days off with my family to recharge. You might or not find an “Adventures in Nodeland” edition in your Inbox next week - mostly dependent on how much time I would have.
This edition includes quite a bit of new releases and code that you might want to check out!
There was a significant release of Mercurius last week and it’s a patch release. In 8.10.0 we have introduced a new feature related to error handling.. and unfortunately we have introduced a significant regression that could cause process crashes on unwanted inputs. This release fixes it/
|
Implement GraphQL servers and gateways with Fastify - Release v8.11.2 · mercurius-js/mercurius
|
|
Implement GraphQL servers and gateways with Fastify - Release v8.11.2 · mercurius-js/mercurius
|
We have also shipped a new release of mercurius-cache that introduce an API to continuously log how many caches hit and miss happened during the observation period. Check it out:
|
Contribute to mercurius-js/cache development by creating an account on GitHub.
|
|
Contribute to mercurius-js/cache development by creating an account on GitHub.
|
I did not have much rest as I started to work on pino@8, removing quite a big chunk of functionality from pino itself: the prettifier. We deprecated this in v7, and now it’s time to remove them completely.
|
100% code coverage back.
This is the start of a v8 planning. We might want to do this sooner than expected and roll it out with Fastify v4.
Removes:
prettyPrint
pino.final()
|
|
100% code coverage back.
This is the start of a v8 planning. We might want to do this sooner than expected and roll it out with Fastify v4.
Removes:
prettyPrint
pino.final()
|
It is possible that pino@7 will have a shorter lifecycle than what we usually done because Node v12 is coming out of support next April.
We are actively working on Fastify@4 and we have decided to remove the “default” implementation of .use with the intent of discourage the use of middlewares:
|
fix #3502 Deprecation of app.use() in next release.
|
|
fix #3502 Deprecation of app.use() in next release.
|
Thanks to a group of new collaborators, we have started working on a new website for Fastify based on docusaurus. Check it out:
|
Contribute to fastify/website-next development by creating an account on GitHub.
|
|
Contribute to fastify/website-next development by creating an account on GitHub.
|
|
One of the key choices you make when building an enterprise Node.js application is the web framework that will serve as its foundation. As part of our Node.js reference architecture effort, we’ve pulled together many internal Red Hat and IBM teams to discuss the web frameworks they’ve had success with.
|
|
One of the key choices you make when building an enterprise Node.js application is the web framework that will serve as its foundation. As part of our Node.js reference architecture effort, we’ve pulled together many internal Red Hat and IBM teams to discuss the web frameworks they’ve had success with.
|
In this above Beth Griggs unveils IBM approach in selecting a Web Framework for your next API, comparing them across different criteria. This is very interesting work that I highly recommend everybody to read.
On similar notes, the next piece about why Developer Experience and Developer Relations go hand-in-hand resonated well with me - this is something that might be of huge interested to you too:
|
There’s a lot of debate about the proper terminology for what we currently refer to as “DevRel.” Many folks are happy with this terminology, but I and others don’t think DevRel (developer relations) is a broad enough term to represent what our field has become over the last half-decade.
|
|
There’s a lot of debate about the proper terminology for what we currently refer to as “DevRel.” Many folks are happy with this terminology, but I and others don’t think DevRel (developer relations) is a broad enough term to represent what our field has become over the last half-decade.
|
Have you ever thought about using a Micro-Frontend architecture? You probably shouldn’t unless you have a pressing need… and in that case they are amazing. Read this article to know more about when to use micro-frontends patterns.
If you are working on a large scale application and the friction between your teams is exponentially increasing as your application grows larger, you are probably considering if the Micro-Frontend pattern is a good fit for you and your organisation.
|
HashiCorp has recently released cdktf, a new library that will enable developers to use the knowledge learnt from using AWS CDK to produce Terraform. This is incredibly interesting as I find CDK much more readable than Terraform.
HashiCorp Terraform allows you to define your infrastructure projects using HashiCorp Configuration Language (HCL). HCL is designed to make it easy for people to read and write configuration that is simple and predictable.
|
If you have not heard of Vite, you have been missing on one of the major forces that are revolutionising how we develop frontend applications. There is a major ecosystem building up - see for yourself:
One of the strongest points in Vite is the ecosystem around it. Vite took responsibilities from frameworks (common web patterns, glob imports, HMR API, SSR primitives, build optimizations), freeing other maintainers from reinventing the wheel each time by offering a common ground where to collaborate, fostering a lot of explorations in the space.
|
I do not understand much of CSS, however this new library deeply resonates with me as it does not require any special tooling to be used. Check it out:
|
Tailwind without tailwind!
|
|
Tailwind without tailwind!
|
At the end I’m covering one of the most-awaited features in Github Actions (my CI of choice): Dependabot Secrets. Read up:
|
