-
-
Notifications
You must be signed in to change notification settings - Fork 208
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Move the fast-json-stringify-compiler to the fast-json-stringify #508
Comments
The main topic is that fjs has always provided a simple function that does all the work. To do what you propose we need to move to an interface like ajv (creating an instance calling new) I think that the fjs simplicity is one of its key element. So I would keep it while planning the its future steps |
We can keep both interfaces. The Compiler entity, in case you want to reuse the context, and fjs if you want to use it once. fjs function will create a new Compiler instance and use it once. |
fast-json-stringify can be used outside of Fastify. fast-json-stringify-compiler is fastify-specific. I'd prefer to keep the two separate unless we need them not to be for a specific reason. |
@Eomm I want to discuss with you this ajv-compilet issue fastify/ajv-compiler#81, but according to FJS. You said that creating an ajv container for each route is overkilling. We actually do it for FJS. I want to change it, but the trick with addUsedSchema wouldn't work in FJS because we need to validate different subschemas instead of the schema itself. Do you think it is possible to add a restriction not to create conflicting global links? We will throw an error if you try to set up two different routes that have different schemas with the same global id. |
Prerequisites
Issue
I want to move the fast-json-stringify-compiler logic to the fast-json-stringify.
Motivation: The fast-json-stringify-compiler binds external schemas to the functional context. What we can do is precompile as many things as we can: clone schemas, add schemas to the RefResolver, modify schemas for Ajv and maybe precompile serializers for those external schemas that don't depend on route schema. Now we do these operations for all external schemas each time when we build a serializer for a route. All these optimizations should be done inside the library because they are based on the implementation and not on the interface.
@Eomm @mcollina WDYT?
The text was updated successfully, but these errors were encountered: