Fastify Developers Who Understand Schemas and Scope
Two concepts carry most of Fastify: JSON schema as the single description of a route, and plugin encapsulation as the way an application is composed. We screen for both, because everything else transfers from ordinary Node experience. Profiles within three business days.
- Profiles in 3 business days
- Two-week replacement guarantee
- No account-manager relay
For Most Services, the Framework Is Not the Bottleneck
We would rather open with this than have you discover it after a migration.
Where the Time Actually Goes
In a typical request the service waits on a database query, calls one or two external APIs, and does a little work of its own. The router and the serialiser account for a small slice of that. Swapping frameworks changes the small slice. It does not touch the query that scans a table because nobody added an index.
Where the Advantage Is Real
High request rates against cheap handlers, where per-request overhead is a meaningful fraction of the total. Services returning large JSON payloads, where schema-based serialisation avoids the generic stringify path. Constrained environments where memory and startup time matter. These are real cases; they are just not every case.
The Better Reason to Pick It
Not speed. Discipline. Fastify pushes you to declare what a route accepts and returns before you write the handler, and that declaration then does validation, coercion, serialisation and documentation from one place. Teams who adopt it for the convention usually stay for the convention, whatever the throughput turned out to be.
If you are still deciding, the framework comparison puts Fastify next to Express, NestJS and the rest without the benchmark theatre.
One Declaration, Four Jobs
The JSON schema attached to a route is not documentation that drifts. It is the thing that runs.
Validation
The body, query string, path parameters and headers are checked against the schema before the handler runs. A bad payload is rejected with a consistent error shape, on every route, without anyone remembering to add a check. This is the part that removes an entire class of defect from a codebase, and it is why the convention is worth adopting even at ordinary traffic.
Coercion
Query strings arrive as strings. A schema that declares a field as a number gets you a number, and the handler stops containing conversion code that is subtly different in three places. Small thing, and it eliminates a familiar category of bug where a value is compared as a string in one branch and a number in another.
Serialisation
When the response is described by a schema, Fastify can compile a serialiser specific to that shape instead of walking an arbitrary object at runtime. That is where a real part of the performance advantage comes from. It also means the response contains exactly the declared fields, which is a genuine security benefit.
Documentation
Because the schema is already there and already accurate, generating an API specification from it is close to free, and it cannot fall out of date the way a hand-written document does. Teams that publish an API to other teams get more value from this than from anything else on this list.
The Trap Nobody Warns You About
- A response schema strips undeclared fields. Add a field to the handler, forget the schema, and it silently never reaches the client
- The client team reports missing data, the developer sees it present in the handler, and the debugging goes in circles
- Schemas maintained by hand next to TypeScript types means two descriptions of the same object drifting apart
- Over-specified schemas that reject valid input from an older client version, discovered only after deployment
- Shared schema fragments edited for one route, changing behaviour on several others that referenced them
What Experienced Teams Do
- Derive schemas from types, or types from schemas, so there is one source and not two
- Treat a response schema change as an API change, reviewed like one
- Keep shared fragments small and obviously shared, rather than large and accidentally shared
- Test that a response contains what the schema promises, not just that the status code was right
- Be deliberate about which routes get a response schema at all — it is a choice, not an obligation
Plugin Encapsulation, and Why Newcomers Fight It
This is the concept that decides whether someone is productive in a Fastify codebase in week one or week four.
What Actually Happens on Register
Registering a plugin creates a child scope. Whatever that plugin adds — decorators, hooks, routes — belongs to its scope and to anything registered inside it. Its siblings do not see it, and neither does its parent. That is deliberate: it is what lets you drop a self-contained feature into an application without it reaching into anything else.
Why It Feels Broken at First
Someone from Express registers a database decorator in one plugin, uses it in another, and gets an undefined property with no obvious cause. The instinct is that something failed to load. Nothing failed; the scope is doing its job. Until a developer holds this model in their head, every problem in the application looks like a mystery rather than a scope question.
Breaking Out Deliberately
Genuinely shared things — a database connection, an authentication decorator, a logger — are registered through a wrapper that opts out of encapsulation so they attach to the parent scope. That is the intended mechanism, not a workaround. The judgement is in deciding what deserves to be global and what should stay contained, and that is a design decision rather than a technical one.
What It Buys You When It Clicks
A feature becomes a plugin with its own routes, hooks, schemas and dependencies, testable on its own by loading only itself. A team can work on separate plugins without touching the same files. And a plugin can be removed by deleting one registration line, which is a property almost no Express codebase has.
Hooks, and the Order They Run In
Fastify gives you named points in the request lifecycle instead of one undifferentiated middleware chain. Knowing which point is which is most of the skill.
| Hook | When it runs | What belongs here |
|---|---|---|
| onRequest | First, before the body has been read | Correlation identifiers, cheap authentication checks, rejecting traffic you do not want to spend a body parse on |
| preParsing | Before the payload is parsed, with access to the raw stream | Decompression, raw signature verification, anything that needs the bytes rather than the object |
| preValidation | After parsing, before the schema is applied | Normalising a payload so validation can succeed, or attaching context the validation depends on |
| preHandler | After validation, immediately before the handler | Authorisation decisions that need a validated body, loading the resource the handler will operate on |
| preSerialization | After the handler returns, before the response is serialised | Reshaping a payload, adding envelope fields, redacting values the schema would otherwise emit |
| onSend | After serialisation, with the outgoing payload | Response headers, compression decisions, last-moment adjustments to the serialised body |
| onResponse | After the response has been sent | Metrics and access logging. Nothing here can change what the client received |
| onError | When a request fails | Observability. The error response shape itself belongs in the error handler, not here |
The Ordering Bug We Plant
An authorisation check written in onRequest that needs a field from the validated body. It works for whoever wrote it because their test payload happened to be well formed, and fails in production for everyone else. The fix is one word — move it to preHandler — and finding it requires actually knowing the lifecycle.
The Scope Bug We Plant
A hook registered inside a plugin, therefore applying only to routes in that plugin, while the developer expected it to cover the whole application. Nothing errors. Some routes are simply unprotected. This is the single most instructive Fastify exercise we run, because it tests both concepts at once.
Adding Your Own Things to the Instance, Request and Reply
What They Are For
Attaching shared capability where the code that needs it can reach it: a database client on the instance, the authenticated user on the request, a helper on the reply. Used well, decorators replace a pile of imports and make the plugin dependency graph explicit.
Declare, Do Not Assign
Properties should be declared up front rather than assigned onto the request when a hook happens to run, because the shape of an object that changes at runtime is slower and harder to reason about. Candidates who know this without prompting have usually profiled something.
The Typing Question
In TypeScript, decorators need their types merged into the framework interfaces or every use is untyped. How a candidate has handled that in a real repository tells you a lot about how carefully they have worked, because the lazy answer is to cast and move on.
Scope Applies Here Too
A decorator added inside a plugin exists only in that scope. Most encapsulation confusion arrives through decorators specifically, which is why our first Fastify question is about exactly this.
What Not to Decorate
Anything specific to a single feature belongs in that plugin, not on the root instance. An instance decorated with twenty things is a shared global under another name, and it makes plugins impossible to test in isolation.
Testing Around Them
Because plugins encapsulate, a plugin can be loaded on its own with a stub decorator standing in for the real dependency. Developers who use that get fast, narrow tests. Developers who do not end up booting the whole application for every case.
What We Ask, and What the Answers Tell Us
Live sessions on real production scenarios. No trivia, no whiteboard, nothing that rewards memorising an API surface.
The Scope Question
Why is a decorator registered in a plugin not visible in a sibling, and how would you share it deliberately. This one question sorts the field faster than anything else we ask.
The Lifecycle Bug
A running service where a hook does not fire for some routes, or fires too early to see the data it needs. We watch the diagnosis, not the clock.
The Schema Review
A pull request where a response schema silently drops a field, and a request schema is stricter than the clients that call it. What they catch is the signal.
The Honest Trade-off
When would you not choose Fastify. A candidate who cannot answer that has an allegiance rather than an assessment, and allegiances are expensive inside a client team.
Can add a route to an existing plugin and write a schema for it. Describes hooks as middleware with different names. Treats a scope surprise as a bug in the framework. Copies the plugin structure that is already there without being able to say why it is shaped that way.
Decides where a plugin boundary goes and what crosses it. Picks the correct hook on the first try and can say why the next one along would be wrong. Knows the response-schema trap from having lost an afternoon to it. Has an opinion on generating schemas from types and a reason for it.
How a Fastify Developer Slots In
You already have the codebase, the standup and the roadmap. What you are missing is capacity.
Week One
Reads the plugin tree before writing anything, because in Fastify that tree is the architecture. Ships something small and real to prove the loop from ticket to deploy works.
You Brief Them
Directly, in your standup and your board. No account manager relaying requirements, because that layer adds delay and loses detail.
Your Review Process
They raise pull requests into your repository and take review comments from your team. If they think something is wrong, they argue it in review like anyone else.
If It Is Not Working
Replacement at no cost inside the first two weeks. Tell us what was wrong rather than just that it did not work, so the next profile is better rather than merely different.
Nearby Pages
Node.js Developers
The broader backend hire when the framework is less important than the engineer.
Node hiringExpress Developers
For the service you are keeping while the new one is built in Fastify.
Express hiringNode Libraries
The ORM, queue, validation and auth choices that sit underneath whichever framework you chose.
The ecosystemPerformance Work
Fixed-scope: profile the service and find out what is actually slow before changing anything.
Performance projectsHiring Fastify Developers
Is Fastify actually faster than Express in a real application?
Yes in the router and the serialiser, and that difference is usually invisible in a real application. If your handler waits on a database query and two external APIs, framework overhead is a rounding error next to the waiting. Where it becomes visible is a service handling very high request rates with small, cheap handlers, or one returning large JSON payloads where schema-based serialisation avoids the generic stringify path. We would rather you profiled the service than took a benchmark chart as a reason to switch.
What is plugin encapsulation and why does it confuse people?
When you register a plugin, it gets its own scope. Anything it adds to the instance is visible to it and to plugins registered inside it, but not to its siblings or its parent. That is what makes a Fastify application composable, and it is also why a developer coming from Express hits a wall on day one, because they expect everything registered anywhere to be available everywhere. To share deliberately, you break out of the encapsulation with a plugin wrapper designed for that purpose. Knowing when to do that and when not to is the difference between someone who has built a Fastify service and someone who has added routes to one.
Do we have to write JSON schemas for everything?
For request bodies and query parameters it pays for itself immediately: one declaration gives you validation, coercion and a rejection shape that is the same on every route. For responses it is optional and it is where the serialisation speed comes from, at the cost of a real trap. A response schema strips fields that are not declared, so adding a field to a handler and not to the schema means it silently never reaches the client. Many teams write a schema generator from their types rather than maintaining two descriptions of the same object by hand.
How do you tell whether a candidate really knows Fastify?
We ask why a decorator registered inside a plugin is not visible in a sibling plugin, and how they would deliberately share it. Then we give them a running service where a hook does not fire for a subset of routes because of where it was registered, and watch them work it out. Both problems are trivial for someone who holds the encapsulation model in their head and genuinely difficult for someone who has only followed examples. Neither is a memory test.
We are on Express. Should we move to Fastify?
Only with a measured reason. A benchmark is not a reason. If you have profiled the service and framework overhead or JSON serialisation is genuinely on the hot path, or you want schema-driven validation as an enforced convention rather than a habit, then it is a sensible move and it can be done route by route behind a proxy rather than as a rewrite. Otherwise the effort is better spent pulling business logic out of your route handlers, which is what usually hurts and which no framework change will fix for you.
Can a Fastify developer work on our existing Express service too?
Almost always, and it is common for one developer to cover both while a team runs two services. The transfer is easy in that direction because Express asks less of you. Going the other way is where people struggle, so if your main codebase is Fastify, say so in the brief and we will screen on the encapsulation model specifically rather than sending a strong Node developer who will spend a week fighting scope.
What does hiring a Fastify developer involve?
Send us the role with the stack, the seniority and the hours you need overlapped. You get two or three pre-screened profiles within three business days, you interview them yourself and choose, and they join your standups and your code review reporting to you rather than to an account manager. Engagements are part-time, full-time or project-based, and if the fit is wrong inside the first two weeks we replace the developer at no cost.
Tell Us What the Service Does
Request rates, payload sizes, who calls it and what it depends on. We will send two or three developers who can work in it, within three business days.