Fastify: Graduation, performance and the future

Fastify is moving from Incubation stage to a Growth Project! Within the OpenJS Foundation, this is a major step forward.

New projects at OpenJS start as incubation projects while maintainers complete the on-boarding checklist to join the Foundation. This includes documenting its infrastructure, transferring the IP, and adopting the OpenJS Code of Conduct. When a project graduates, they’ve readied their project for Foundation support. At OpenJS, we share best practices and reduce redundant administrative work across projects, such as non-technical governance, to help projects grow.

The Cross Project Council (CPC) centralizes coordination among projects as well as certain technical governance and moderation processes, and oversees the progression of projects between stages of their life cycles. Fastify has passed all of its requirements and we are happy to welcome them as a Growth Project!

To find out more about Fastify and what’s next, we talked with Matteo Collina, one of the Lead Maintainers of the Fastify team, Technical Director at NearForm, Node.js Technical Steering Committee member and OpenJS Foundation Cross Project Council member.

Are there any benchmarks that people should pay attention to regarding web performance?

I often say that “performance does not matter, until it absolutely does.” Most websites and applications do not need to be fast or scale to thousands of servers. Most developers at small and big companies alike will not (and should not) care about performance at all. Their bigger concerns are maintainability and speed of delivery. As a result, applications become bigger and slower.

As an example, a lot of developers care only about the latency of a single request when the server is idle, completely avoiding the latency and load introduced by server-side processing. Providing a snappy user experience requires both the front end and the backend to work in concert and play to each other strengths.

What are the most important metrics people should pay attention to with regard to web performance (faster networks, run time)?

The most important metric for Node.js applications is event loop latency. We define this as the time needed to process some part of an incoming http request. The higher the throughput of our application, the smaller this needs to be. Let’s make a quick example. Let’s imagine a Node.js server that can process an http request in 10 milliseconds of CPU time. Do you think this server is fast? Given that most deployments have 1 CPU per container (or even less), we can say that a single container can process around 100 requests per second.

However, we cannot say if our server is fast or slow, as it depends on the load. If our server will receive less than 100 req/sec it would appear snappy and “fast.” But if it’s over 100 req/sec, the service will now “lag behind” and the latency of every request will start increasing.

Fastify helps deploy Node.js applications at scale by applying some load-shedding techniques in the under-pressure plugin. Essentially if the server is busy it will start rejecting requests: the load balancer will try to serve them from another instance.

Now that Fastify has graduated incubation, what’s next for the project in terms of big milestones?

We’ll rest and recover! The last few months has been a race to ship Fastify v3, and now we are graduating!

It’s time to start planning Fastify v4 for 2021.