DEV Community

Schema Validation with Zod and Express.js

Francisco Mendes on December 01, 2021

Overview In the past I've done articles on how we can use libraries like Joi and Yup to create middleware that does input validation com...

Read full post

Brian McBride • Dec 28 '21

The problem is that the types are not defined on the request. That's a general problem with middleware anyway. I have never liked modifying the request object. While it is one of the neat things about Javascript, it can cause confusing bugs when some middleware has an issue.

I might do something like:

import type { Request, Response, NextFunction } from 'express';
import { AnyZodObject, ZodError, z } from 'zod';
import { badRequest } from '@hapi/boom';

export async function zParse<T extends AnyZodObject>(
  schema: T,
  req: Request
): Promise<z.infer<T>> {
  try {
    return schema.parseAsync(req);
  } catch (error) {
    if (error instanceof ZodError) {
      throw badRequest(error.message);
    }
    return badRequest(JSON.stringify(error));
  }
}

Then use that function at the top of my express object.

const { params, query, body } = await zParse(mySchema, req);

I'm a big fan of clearly functional/declarative code.
While it is not quite as DRY as putting everything into middleware, I don't mind if my routes have a stack like: (I'm using an async wrapper for express)

app.get('/', (req, res, next) => {
  const token = await validateToken(req);
  const { params, query: {page, pageSize}, body } = await zParse(mySchema, req);
  await myHandler({token, page, pageSize})
})

Sure, every route has very similar code with mySchema and myHandler the only major differences. The main point here is that anyone can see what this route needs. In this case, a token, page number and the pagination size. With zod I can define defaults, so those values can be required in the handler. And that lets me keep default settings a bit more clean as well.

Lars Rye Jeppesen • May 15 '23

I love this, I personally always do my route parsing in the route, as opposed to the middleware, for the same reason: readability of the code. Middleware can quickly become something that magically changes the request object, making it (sometimes) harder to understand what's really going on when debugging or bug fixing.

I don't mind have a "parseRequest" function in my endpoint which parses and returns the props that the endpoint needs. Cheers

Syed Aman Ali • Jul 25 '23

`import type { Request, Response, NextFunction } from 'express';
import { AnyZodObject, ZodError, z } from 'zod';
import { badRequest } from '@hapi/boom';

export async function zParse(
schema: T,
req: Request
): Promise> {
try {
return await schema.parseAsync(req);
} catch (error) {
if (error instanceof ZodError) {
throw badRequest(error.message);
}
return badRequest(JSON.stringify(error));
}
}`

return await schema.parseAsync(req);

the await is necessary otherviwe the error won't come in the catch block of the zParse instead it will come in the catch block of the function which is calling it.

Francisco Mendes • Dec 28 '21

It's my first time seeing such an approach. Being completely honest, I find it quite interesting. Obviously it's not something that's very generalized, but it's something I'll point out and try out in the future. Thank you very much for your comment, it has an interesting perspective✌️

Brian McBride • Dec 29 '21

Obviously it's not something that's very generalized

I love how you said that. This is the trap that we fall in as developers.
While I always say use a well supported lib before going to write your own, the details of our best practices can be improved.

Why do we modify the Request object in Express? How do we expect the developer downstream to know what we added or changed? If we look at more opinionated frameworks, we start to see the use of a context object that is clearly typed and defined. The same javascript developer who extolls the virtue of immutability in their React state engine is the same person who will arbitrarily modify their backend Request source of truth.

I've personally wasted hours going "why doesn't this work" only to find out some middleware we put in was changing the request or response objects.

There is a functional pattern that you could use and it would be clearly declarative and let you modify the data as it passes from function to function and that is using RxJS. If we truly treat the HTTP request as a stream (which it is), RxJS unlocks a LOT. Most of the time, it is too much unless you use observables often and feel comfortable with them.

Outside of programming by tradition, the other advantage of what I've done above is that you get the coercing from zod. In your validation pattern, you aren't going to get defaults, have unwanted keys stripped from your objects, or have transformations applied.

const mySchema = z.object({
  query: z.object({
    page: z.number().optional().default(0),
    pageSize: z.number().optional().default(20),
  }),
});
const { params, query: {page, pageSize}, body } = await zParse(mySchema, req);

Based on my schema, I know 100% that the query page is defined and it is a number with a default of 0 and pageSize is a number, is defined, and has a default of 20. Params will be undefined and body will be undefined.

Felipe Lima • Sep 13 '23 • Edited

Or just

const createSchema = z.object({
  body: z.object({
    name: z.string({ required_error: "name is required" }),
    version: z.string({ required_error: "name is required" }),
  }),
});

type createType = z.infer<typeof createSchema>;

const { body }: createType = req.body;

Md Shahriyar Alam • May 18 '23

How do we add a error handler using this approach?

Bassam • Oct 15 '23

Error handling is already there. If the zod parse errors out, a status 400 response is sent.

Oliver Sagala • Sep 18 '23

How can you make this function return a conditional partial type as well, for say updating an item?

Bassam • Oct 15 '23

You can adjust req.body, for example, as needed. All subsequent middlewares/functions will see this change.

James Bender • Oct 14 '22

Hi,

I tried following this tutorial, but I'm getting this error when I run it:

Error: Must use import to load ES Module

I've run into this on other projects before, and went through the "usual suspects" of changes to try to get it to work, but I was not able to. Do you know what the issue might be?

I'm using Node 16.15.0

Thanks