Conversation
|
I haven't looked through all of this to determine how it affects Joi support, but I can say that I no longer have need of that accursed library. I think we definitely need to improve schema support in v3. We advertise having full support for JSON Schema, but as soon as you start trying to use references the whole thing falls apart in various ways. I fully support moving the schema container out of Fastify itself and merely accepting one being supplied at boot time. |
From 1.15 it supports it at 3 levels of nesting
Yes, because those people are ourself 😆
I will test all the past use cases and will write a "how to migrate" guide to include it in the release message for v3 |
|
Still 45 failing test before finish + docs The backbone code is complete I think. The logic right now is:
The default code flow is:
|
|
This should significantly improve our cold start time on serverless, definitely +1. |
| * Compiler for FastifySchema Type | ||
| */ | ||
| export type FastifySchemaCompiler = (schema: FastifySchema) => unknown | ||
| export type FastifySchemaCompiler = (method: string, url: string, httpPart: string, schema: FastifySchema) => unknown |
There was a problem hiding this comment.
@Ethan-Arrowood I'm not sure, but the export interface FastifySchema could be wrong cause the user will receive as input a plain schema, not the complete schema configuration
fastify.post('/the/url', {
body: bodyJsonSchema,
querystring: queryStringJsonSchema,
params: paramsJsonSchema,
headers: headersJsonSchema
}, handler)
The user will get 4 calls with bodyJsonSchema, queryStringJsonSchema, paramsJsonSchema, headersJsonSchema each one
Could you help me with the TS test? I need only some suggestions 😇
There was a problem hiding this comment.
I'm confused -- i thought those properties fall under the schema property on the route options object. I noticed in your unit tests theres an reponse property now added to the schema so that should be added to the FastifySchema interface.
These schema properties are specified as type unknown because this allows the user to tell TypeScript what they are strictly. If we used something like { [k: string]: any } then we are making the type system non-strict by default and that does not lead to a great user experience. Check out the Schema section in my TS docs for more info.
There was a problem hiding this comment.
i thought those properties fall under the schema property on the route options object
This is correct
in your unit tests theres an reponse property now added to the schema so that should be added to the FastifySchema interface.
This feature is already in place from master
My concern is that the FastifySchemaCompiler want a FastifySchema as input (schema parameter) but this parameter is a JSON Schema.
I think we need a different type here since FastifySchema works for route's configuration only.
I'll try to explain me by example:
// want a JSON schema input
fastify.addSchema({
$id: 'test',
type: 'object',
properties: {
id: { type: 'number' }
}
})
// want a `FastifySchema` type
fastify.get('/:id', {
handler: (req, reply) => {
reply.send({ id: req.params.id * 2, ignore: 'it' })
},
schema: {
params: { $ref: 'test#' },
response: {
200: { $ref: 'test#' }
}
}
})
fastify.setValidatorCompiler((method, url, httpPart, schema) => {
// looking the route above, the args are:
- httpPart = "params"
- schema = { $ref: 'test#' }
})
There was a problem hiding this comment.
this looks good to me now
|
Can you please update the PR description to match the current status of this PR? |
Done |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
|
Stalebot, I'm waiting for @Ethan-Arrowood 👍 |
Ethan-Arrowood
left a comment
There was a problem hiding this comment.
LGTM 😄 (sorry for missing this, im still trying to figure out github notifications lol)
|
@fastify/core someone would like to check this PR? Here all the changes: I would like to merge it in next before merging master since there are a couple of fixes in v2 that need to be adapted |
|
I really can't review it other than to say the code looks good. I'll need time to try it in an RC, and I don't even know when I'll have that time. |
|
No problem! |
|
Has the binary format been removed in v3? |
I don't understand what you mean. |
|
Sorry, I was not clear enough, (and did not even investigate)... |
|
Now I know why.... sorry my fault... |
- remove error `FST_ERR_SCH_BUILD`. This error was removed in fastify#2023 , and doesn't exist in current master branch [error.js](https://github.com/fastify/fastify/blob/master/lib/errors.js). These lines were re-added to the file in #13f51c06ccc4f117fd8fa1892d8edefc554746b2.
|
This pull request has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs. |
This PR includes:
Changes
schemaCompilerhas been renamed tovalidatorCompilerfor clarity: this property is a function that must return a new function to validate the request partsvalidatorCompilerfunction has a new signature:(method, url, httpPart, schema)to improve the tools that we can build around it (like store the generated functions without recompiling them on start)Addition
serializerCompilermethod has been added to open to customization of the default serializer (default: fast-json-stringify)Breaking changes
schemaResolverfeature: it is not needed anymore without the shared schema "replace-way" since we are not resolving the$refkeyword anymore** I have tested a lot of configurations to don't let the users suffer the upgrade, and if we wrote this:
Migration guide
removed the JSON shared schema [replace-way]
You wrote this:
Now you can write this:
removed the
schemaResolverfeatureYou wrote this:
Now you can write this:
How it works (default)
When a route with a schema for validation (
query, params, path, body) is found, an AJV instance is built. The instance will be the same for all the children plugins unless the user customizes thevalidatorCompilerper context or per route.The same happens for the serialization.
Additional optimization:
When two different contexts need to build an AJV instance. If the
ajv custom optionsand the shared schema (added with.addSchema) are the same, these two contexts will use the same AJV instance.Checklist
npm run testandnpm run benchmark