Question 1

Should I use Fastify or Express for a new Node.js API in 2026?

Accepted Answer

For a new API, Fastify is the better default. You get JSON Schema validation, OpenAPI generation, structured logging, and 2x the throughput out of the box — all features you would otherwise bolt onto Express via ajv, express-openapi, pino-http, and so on. Express remains a reasonable choice only if your team has deep Express muscle memory and the API is throwaway/internal. Every new Indian fintech (Razorpay, Cred-style) and dev-tools company (Postman) building today picks Fastify.

Question 2

How much does a Fastify developer earn in India in 2026?

Accepted Answer

₹7-22 LPA for mid-to-senior backend developers with Fastify as their primary framework. The role title is usually Node.js/Backend Engineer rather than Fastify-specific, but Fastify experience is a strong signal in interviews and resume screens at performance-conscious teams. FinTech (Razorpay, Cred) and dev-tools (Postman) pay at the upper end; mainstream SaaS pays mid-range.

Question 3

Is Fastify production-ready?

Accepted Answer

Fastify has been production-ready since version 3 in 2020. Version 5 (October 2024) is the current stable line and used at Microsoft, Walmart, American Express, and dozens of Indian companies. The core team includes Node.js TSC members, releases follow semver strictly, and the LTS policy is published — pick a 5.x release for any new service.

Question 4

Do I need TypeScript to use Fastify?

Accepted Answer

No, but it pays off quickly. Fastify ships first-class TypeScript types out of the box, and the @sinclair/typebox or zod-to-json-schema integrations let you write a single schema that drives runtime validation AND generates compile-time types automatically. For greenfield TypeScript projects, this combination eliminates an entire class of 'I forgot to validate that field' bugs because the request object's TypeScript type is generated from the same schema that Ajv validates at runtime — they cannot disagree. Many Indian teams (Postman, Walmart Labs, several YC-funded fintech startups) use TypeBox plus Fastify as their default backend stack precisely because of this single-source-of-truth property. The downside of TypeScript is the build step and the slightly slower iteration loop, but tsx and ts-node-esm make dev-time TypeScript essentially as fast as plain Node in 2026.

Question 5

How is Fastify different from NestJS?

Accepted Answer

NestJS is an opinionated framework (TypeScript decorators, modules, dependency injection à la Angular) that runs on either Express or Fastify under the hood — Fastify is the underlying HTTP framework while NestJS adds an architectural layer on top. Fastify is the underlying framework with no opinion on application architecture: you choose your own dependency wiring style (autoload, decorators, manual factories). Pick Fastify when you want full control, minimal magic, and the freedom to structure your app however you like. Pick NestJS when you want Angular-style structure, a built-in DI container, and don't mind the conventions. NestJS running on the @nestjs/platform-fastify adapter gives you NestJS's developer experience with roughly 80% of raw Fastify's performance — the loss comes from NestJS's interceptor and guard layer, not from Fastify itself. For most teams, the choice comes down to whether you value architectural conventions (NestJS) or raw performance and flexibility (Fastify).

Question 6

What changed in Fastify 5 versus Fastify 4?

Accepted Answer

Fastify 5 (released October 2024) dropped support for Node 18, requiring Node 20 LTS minimum. It switched the default JSON Schema engine to Ajv 8, removed deprecated APIs (request.connection, reply.context, request.routerPath), tightened TypeScript types significantly (catching many latent bugs in user code), and made several internal optimizations to the hook chain. Migration from Fastify 4 to 5 is usually one focused afternoon for a typical mid-size app — most projects just need to upgrade their plugins to the matching v5-compatible versions and bump the Node version in CI and Dockerfiles. New projects in 2026 should start on Fastify 5.x; do not start anything new on version 4 because v4 is in maintenance mode and will not receive new features. The fastify migration guide on the official docs is excellent and walks through every breaking change with a one-line fix.

Question 7

Which Indian companies are hiring Fastify developers in 2026?

Accepted Answer

Fastify experience is strongly valued at Razorpay (payment APIs), Postman (mock servers and platform services), Cred (rewards and ledger APIs), Zerodha (some tooling backends), CRED Mint, Slice, and Jupiter Money in the fintech space. In the SaaS space, Postman, Hasura, and several Y Combinator-funded Indian startups use Fastify as their default Node.js framework. For broader Node.js backend roles, mentioning Fastify experience in interviews signals you care about performance and modern patterns — even teams not using it day-to-day will react positively. Salaries range from ₹7-12 LPA for 2-4 years of experience, ₹12-18 LPA for 4-7 years, and ₹18-22+ LPA for senior backend engineers with deep Fastify or Node.js performance optimization expertise.

Question 8

What is Fastify and why was it created when Express already existed?

Accepted Answer

Fastify is a Node.js web framework created in 2016 by Matteo Collina (Node.js TSC member) and Tomas Della Vedova, designed around a single principle: minimum overhead per request. Express was created in 2010 and its routing, body parsing, and middleware pipeline carry historical baggage that cannot be removed without breaking the ecosystem. Fastify solves three specific problems Express handles poorly. First, JSON serialization is the slowest part of most APIs, so Fastify uses fast-json-stringify with a precompiled schema instead of the generic JSON.stringify. Second, Express middleware runs sequentially with chained callbacks and closures, while Fastify compiles all hooks for a route into a single function chain at registration time. Third, Express has no built-in validation, so Fastify uses Ajv with JIT-compiled JSON Schema validators for both incoming requests and outgoing responses. The cumulative result is roughly 2x more requests per second on identical hardware in real-world benchmarks like the techempower JSON test. Fastify is now used in production at Microsoft (parts of Azure), Walmart (checkout APIs), American Express (member services), and several Indian companies including Razorpay (payment APIs), Postman (mock servers), and a growing number of fintech startups. The framework has been actively maintained for nine years with strict semver, a published LTS policy, and a release cadence aligned with Node.js LTS lines.

Question 9

How do you create a basic Fastify server and define a route?

Accepted Answer

Import the factory function, call it to create an instance, register routes, and call listen. Unlike Express where app.listen takes a callback, Fastify's listen returns a Promise that resolves when the server is bound to the port and ready to accept connections. You can either await it or pass a callback for legacy code, but async/await is the idiomatic style in 2026. The route handler receives request and reply objects with richer APIs than Express's req and res. Return values from async handlers are automatically sent as the response body, so you rarely call reply.send() explicitly unless you need to set a status code, set headers, or send before doing additional async work. The factory function accepts options including logger configuration, body size limits, trust proxy settings (essential for behind-load-balancer deployments to get correct client IPs), and HTTP/2 enablement. Always bind to host 0.0.0.0 inside Docker containers — the Fastify default is 127.0.0.1 which is loopback-only and will leave you with a server that works on the host but is unreachable from outside the container, a very common rookie production bug.

Question 10

What is JSON Schema validation in Fastify and how do you attach a schema to a route?

Accepted Answer

Fastify uses JSON Schema (draft 7 by default, draft 2020-12 available via configuration) for both request validation and response serialization. You attach a schema object to the route definition under the schema property, with sub-keys for body, querystring, params, headers, and response. Fastify compiles the schema with Ajv at route registration time, not per request — Ajv generates a JavaScript validator function that is essentially a long if/else chain checking each property. This means validation cost is fixed at boot and trivial at runtime, typically under a microsecond per request. If a request fails validation, Fastify automatically returns a 400 with a structured error message containing the path to the offending field and a human-readable description. You can customize the error format with a setErrorHandler if your API contract requires a specific shape. The same schema serves three purposes simultaneously — request validation, response serialization speedup via fast-json-stringify, and automatic OpenAPI documentation if you register @fastify/swagger. This single-source-of-truth approach is one of the biggest reasons teams switch from Express plus a pile of separate validation/docs/serialization libraries.

Question 11

What is the difference between request.params, request.query, and request.body?

Accepted Answer

request.params holds URL path parameters declared with the colon syntax in the route path (/users/:id, /posts/:slug). request.query holds the parsed querystring object from the URL after the question mark (/users?page=2&limit=10 becomes { page: '2', limit: '10' }). request.body holds the parsed request body, populated only for POST/PUT/PATCH/DELETE methods with a body content type. Fastify automatically parses application/json and application/x-www-form-urlencoded out of the box; for multipart/form-data uploads you need to register @fastify/multipart; for XML or other formats you register a custom content type parser via fastify.addContentTypeParser. All three are plain JavaScript objects. The crucial difference from Express is type coercion via the schema: in Express, request.query.page is always the string '2' and you must parseInt it yourself, but in Fastify if you declare page as integer in the querystring schema, Ajv coerces it to a real number before the handler runs. The same applies to booleans, arrays (using the array type with collectionFormat or csv-style parsing), and dates (with format: 'date-time'). This eliminates an entire category of off-by-string-vs-number bugs that plague Express codebases.

Question 12

What is a Fastify plugin and how is it different from Express middleware?

Accepted Answer

A plugin in Fastify is an async function that receives the Fastify instance and an options object as arguments. Plugins are the unit of composition in Fastify — they register routes, hooks, decorators, content type parsers, error handlers, and even other plugins. The fundamental difference from Express middleware is encapsulation: plugins create a child scope by default, so anything you register inside a plugin (routes, hooks, decorators) is only visible to that plugin's scope and its descendants, not to the parent application or sibling plugins. This solves the classic Express problem where adding a logging middleware globally affects every route — including healthchecks where you don't want noise — and where one plugin can accidentally override another's request property. Encapsulation makes Fastify codebases predictable as they grow: you can ship a third-party plugin to production knowing it cannot accidentally pollute the rest of your app. To make a plugin's additions visible to the parent (a database connection, an auth helper, a Redis client — things you genuinely want everywhere), wrap the plugin function with fastify-plugin (conventionally imported as fp). The rule of thumb that experienced Fastify developers internalize: feature plugins (route groups) should NOT use fp, infrastructure plugins (db, redis, auth) SHOULD use fp.

Question 13

How do hooks work in Fastify and what are the most common hook types?

Accepted Answer

Hooks are lifecycle callbacks that run at specific points during a request or application lifecycle. The request lifecycle hooks, in order, are: onRequest, preParsing, preValidation, preHandler, preSerialization, onSend, onResponse, onTimeout, onError. Each hook receives the request and reply objects and either an async function or a callback. The two most-used in practice are onRequest (runs before body parsing, ideal for logging, rate limiting, IP allowlisting, and any check that does not need the request body) and preHandler (runs after validation but before your handler, ideal for authentication and authorization checks). preParsing lets you intercept and rewrite the raw request stream — used for things like decompression or end-to-end encryption. preSerialization lets you mutate the response before it is serialized to JSON, useful for adding HATEOAS links or filtering fields based on user permissions. Application-level hooks include onReady (runs once when the server is fully booted, useful for warming caches or registering with a service discovery system) and onClose (runs when the server is shutting down, essential for closing DB pools, flushing logs, and draining connections gracefully). Hooks are registered with fastify.addHook(name, handler) and respect plugin encapsulation — hooks registered inside a plugin only run for routes in that plugin's scope, which is one of Fastify's most powerful features for keeping concerns isolated.

Question 14

What are decorators in Fastify and when should you use them?

Accepted Answer

Decorators attach values or functions to the Fastify instance, the request object, or the reply object. They are the recommended way to share resources (database connection, Redis client, auth helpers, business logic functions) across routes without resorting to module-level globals or singletons that are hard to test. Use fastify.decorate('name', value) for instance-level decorators accessible as fastify.name in any route, fastify.decorateRequest for per-request properties accessible as request.name in handlers and hooks, and fastify.decorateReply for per-reply properties. The performance advantage is rooted in V8's optimization model: V8 uses hidden classes to optimize property access on objects, and these hidden classes are stable only if every instance has the same shape. By decorating at startup, you tell Fastify the full shape of the request and reply objects ahead of time, so V8 can generate optimized property-access code that stays hot for the lifetime of the process. Decorating inside a route handler or hook by writing request.someNewProperty = value is the classic anti-pattern — V8 sees a new hidden class on every request, deoptimizes the inline caches, and your throughput drops 20-40%. Always decorateRequest with the correct default value (null for objects, '' for strings, 0 for numbers) at startup, then mutate it in hooks.

Question 15

How do you handle errors in a Fastify route?

Accepted Answer

Three options, increasing in sophistication. First, throw an error in an async handler — Fastify catches it and returns a 500 with the error's message in the response. Second, throw an instance from @fastify/sensible's httpErrors (notFound, badRequest, unauthorized, forbidden, conflict, internalServerError, and so on) to set a specific status code with a properly-formatted error response that follows the Problem Details for HTTP APIs convention (RFC 7807). Third, register a global error handler with fastify.setErrorHandler — this is invoked for any error thrown from any handler or hook in the encapsulation scope where it was registered. Validation errors from JSON Schema automatically return 400 with a structured error message without any code from you. The setErrorHandler approach is the production standard because it lets you log errors uniformly with the request ID for traceability, redact secrets from error messages (database connection strings often leak in error messages), format the response per your API contract, emit metrics to your APM (SigNoz, Datadog), and decide which errors to expose to the client versus mask as a generic 500. Avoid scattering try/catch in every handler — let errors bubble up and handle them centrally. The one exception is when you can recover (retry once, fall back to a cache, return a default), in which case localized try/catch is correct.

Question 16

What is the role of the logger in Fastify and why is Pino used?

Accepted Answer

Fastify ships with Pino, the fastest JSON logger for Node.js, as a first-class dependency — also written by Matteo Collina, the Fastify creator. The logger is enabled by passing { logger: true } or a config object to the Fastify factory. Pino logs are JSON by default and asynchronous — they write to stdout via a transport worker thread, so the request handler is never blocked on I/O even under heavy logging. Benchmarks show Pino logs roughly 5x faster than Winston and 10x faster than Bunyan. Every request automatically gets a child logger accessible via request.log with a unique reqId injected — so request.log.info(msg) emits a log line tagged with the request ID, letting you trace a single request across all the log lines it produces in your log store. In production, ship logs to stdout and let your container runtime (Kubernetes, Docker) or a sidecar (Vector, Fluent Bit, OpenTelemetry Collector) forward them to your log store (ELK, Datadog, SigNoz, which GoodSpace itself uses). Never write logs to files in containerized production — the container filesystem is ephemeral and your logs disappear on restart. For local development, pipe stdout to pino-pretty for human-readable colorized output. Always configure the redact option to strip authorization headers, cookies, and any field that could contain PII or secrets before logs leave the process.

Question 17

How do you enable CORS in a Fastify application?

Accepted Answer

Use the official @fastify/cors plugin, which handles preflight (OPTIONS) requests and sets the appropriate Access-Control-* response headers. Register it before any routes that need CORS support — registration order matters in Fastify because plugin encapsulation means CORS hooks only apply to routes registered after the CORS plugin within the same scope. For production, set origin to an explicit list of allowed domains. Never set origin to true (which echoes the request Origin header back, effectively allowing any site to call your API with cookies, defeating CORS protection) or use the wildcard '*' if you need cookies. If you need to allow credentials (cookies, Authorization header), set credentials: true and origin must be a specific list, never a wildcard — the browser will reject the response otherwise. For dynamic origin lists (multi-tenant SaaS with per-tenant custom domains), origin can be a function that returns a boolean given the request Origin header. Set maxAge to a reasonable value (24 hours = 86400 seconds is common) to let the browser cache the preflight response, reducing OPTIONS round-trips on subsequent requests. In Indian SaaS deployments where the web app and API often live on different subdomains (app.company.com and api.company.com), CORS configuration is the single most common source of 'works in postman but not in browser' bugs.

Fastify Interview Questions

What is Fastify and why was it created when Express already existed?

How do you create a basic Fastify server and define a route?

What is JSON Schema validation in Fastify and how do you attach a schema to a route?

What is the difference between request.params, request.query, and request.body?

What is a Fastify plugin and how is it different from Express middleware?

How do hooks work in Fastify and what are the most common hook types?

What are decorators in Fastify and when should you use them?

How do you handle errors in a Fastify route?

What is the role of the logger in Fastify and why is Pino used?

How do you enable CORS in a Fastify application?

What is the difference between reply.send() and returning a value from a handler?

How do you set HTTP status codes and custom response headers in Fastify?

Explain Fastify's plugin encapsulation model and how to break it intentionally.

Why does Fastify use schema-based serialization and how much faster is it than JSON.stringify?

How does the Fastify hook execution order work, especially with multiple plugins?

How do you implement JWT authentication in Fastify?

How do you organize a Fastify app with autoload to scale to dozens of routes?

How do you connect Fastify to PostgreSQL in production?

How do you write unit and integration tests for Fastify?

How do you implement rate limiting in Fastify?

How do you generate OpenAPI documentation for a Fastify API?

What is the difference between fastify.register() and fastify.use()?

How do you stream a large file or response in Fastify?

How do you handle WebSocket connections in Fastify?

How do you handle environment-specific configuration in Fastify?

How would you architect a Fastify service to handle 20,000+ requests per second?

How do you debug a memory leak in a Fastify production service?

Explain Fastify's avvio plugin loader and how it controls startup order.

How do you implement multi-tenancy in a Fastify SaaS application?

How does Fastify achieve such high throughput compared to Express, mechanically?

Companies Hiring Fastify

Salary Insights

Frequently Asked Questions