Closed tobysmith568 closed 2 years ago
Hi @tobysmith568, from my current project, the input validation (or request validation) is actually done in a middleware layer
For example, in the middleware example, we validate the email with external service, which can be replaced with other validation tools like zod
, joi
& yup
I have also thought about this as a standard middleware adaptor but it really depends on people's usage
Hey @Howard86. Yeah that's on me, I should have looked into your middleware more deeply before posting.
Perhaps I'm missing something, is there a way to run middleware on specific HTTP methods?
I'd want to validate GET/POST/DELETE/etc differently, perhaps something like this?
router.use(myAuthMiddleware);
router.useOnPost(postBodyValidatorMiddleware);
router.useOnDelete(deleteBodyValidatorMiddleware);
router.get(getHandler);
router.post(postHandler);
router.delete(deleteHandler);
Perhaps I'm missing something, is there a way to run middleware on specific HTTP methods?
I'd want to validate GET/POST/DELETE/etc differently, perhaps something like this?
Hmm looks like a quick solution. Do you have references that other libraries do something similar?
This new api will change the implementation of middleware and how it works with router, let me think about it...
If I were in a similar situation, I would probably finish everything in one handler (if this middleware is not supposed to be shared)
router.post(req => {
const userDto = validateUser(req)
return createUesr(userDto)
})
No I don't have an example of another library which follows this pattern.
I would probably finish everything in one handler
Yeah, currently the first line of my handler is calling what would be the middleware.
The reuse I'm envisioning would be across endpoints rather than across http methods. Perhaps for three different endpoints the GETs can be hit unauthorised but POSTs and DELETEs need to run through an auth middleware.
There's still no reason why the first line of all the POSTs and DELETEs can't be the call to the middleware though.
Hey, would you consider adding built-in support for request model validation? Perhaps using a library like Zod?
(If so, I'd be happy to contribute / submit a PR with my thoughts on how it could look)
You can see here a file of mine which uses your library and has a custom method for validating the incoming request body.
Here you can see it after I refactored it to use Zod.
Zod + your library's catching of
Error
is a pretty good mix. The Zod methodparse
(used on line 20) throws aZodError
which means that posting an incorrect request body to my API in my project might result in the following example response:Would you consider adding richer support for either Zod or another library of your choice so that the API response doesn't return JSON in a string?
I have a couple of thoughts on approaches:
1) The lighter of the two could be modifications to your
error-handler.ts
file to specifically look for theZodError
and handle it there with zero config/setup required for consumers of your library. Users would still need to do what I've done on the first line of mypostHandler
where I call the validatorsparse
method myself.2) The more in-depth approach could be something like:
Ideally this second approach would somehow modify the
NextApiRequest
type to have a strongly-typedreq.body
field. In this approach users wouldn't need to call the validator themselves because your library would call it for them.Thanks for reading, I'm happy to hear any thoughts! :)