Expresskit validator #72
Conversation
docs/VALIDATOR.md
Outdated
| summary?: string; // Short summary for OpenAPI | ||
| description?: string; // Detailed description for OpenAPI | ||
| tags?: string[]; // Tags for grouping (e.g., for OpenAPI) | ||
| manualValidation?: boolean; // Default: false. If true, call req.validate() manually. |
There was a problem hiding this comment.
It's not about a contract, but about internal logic of withContract.
In my opinion, it would be better to separate the OpenAPI settings and the HoF settings:
withContract(RouteContract, settings?: {manualValidation?: boolean})
src/validator/index.ts
Outdated
| // If there's no schema defined for this status code, or it's a 204, or data is undefined, don't send content | ||
| const hasSchema = | ||
| config.response.content[statusCode as number]?.schema !== undefined; | ||
| if (!hasSchema || statusCode === 204 || data === undefined) { |
There was a problem hiding this comment.
Maybe we should leave control over the 204 code to consumers?
src/validator/openapi-registry.ts
Outdated
| * @returns The OpenAPI schema object | ||
| */ | ||
| getOpenApiSchema(): OpenApiSchemaObject { | ||
| if (cachedSchema) { |
There was a problem hiding this comment.
Do we really need cache here? getOpenApiSchema is called only once – https://github.com/gravity-ui/expresskit/pull/72/files#diff-bb8ff0dd16ff286e4086240831f70dd9233de8896f2f50219eeff29414affe64R181
| } | ||
| }); | ||
|
|
||
| if (ctx.config.openApiRegistry?.enabled && openapiRegistry) { | ||
| const openApiSchema = openapiRegistry.getOpenApiSchema(); |
There was a problem hiding this comment.
Calculating openApiSchema can take a long time and block the application from starting. Is it possible to wrap these lines in setImmediate(...)?
| import jwt from 'jsonwebtoken'; | ||
|
|
||
| // Add OpenAPI security scheme metadata to your auth handler | ||
| const jwtAuthHandler = bearerAuth('myJwtAuth')(function authenticate(req, res, next) { |
There was a problem hiding this comment.
Does it work correctly with global declared appAuthHandler?
|
|
||
| The `res` object in your handler is enhanced with the following methods: | ||
|
|
||
| - **`res.sendTyped(statusCode, data?)`**: |
There was a problem hiding this comment.
sendTyped is still not the best name.
I'm not sure if patching the original res.send() is acceptable here, but if it is, I suggest the following naming:
res.send()– for static type checking (nowres.sendTyped()).res.sendOriginal()– for original method (nowres.send()).res.sendValidated()– without any changes.
Or use res.contract.send() and res.contract.sendValidated().
@resure what do you think about this?
There was a problem hiding this comment.
The original express method should not be patched. Such an override can have a lot of side effects and is probably not worth it.
res.contract.send()
I'm not 100% sure if this is better than sendTyped, but maybe it could be a logical way to move all new helpers to new namespaces (req.contract., res.contract.). The only worry is that it might look pretty long that way.
There was a problem hiding this comment.
@imsitnikov @resure what you think about having semantic methods: req.ok(data), req.created(data), req.badRequest(data), etc, depending on what is defined in schema? They will have static validation.
And probably req.ok.validated(data) for dynamic validation?
There was a problem hiding this comment.
Looks like additional pollution of the req object, and one method will be easier to maintain than many.
Overall, I'm okay with res.contract.send() or res.sendTyped(), but I'm not the decision maker here.
ExpressKit Validator
Validation framework for ExpressKit that provides:
Features
TODO
req.bodywill be already validated in a handler