Move the fast-json-stringify-compiler to the fast-json-stringify

[ivan-tymoshenko]

Prerequisites

• I have written a descriptive issue title
• I have searched existing issues to ensure the issue has not already been raised

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?

[Eomm]

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

[ivan-tymoshenko]

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.

[mcollina]

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.

[ivan-tymoshenko]

@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.