Skip to content
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

SchemaRepository Injection into OpenAPIContract #93

Open
jawaff opened this issue Nov 26, 2024 · 1 comment
Open

SchemaRepository Injection into OpenAPIContract #93

jawaff opened this issue Nov 26, 2024 · 1 comment
Labels
enhancement New feature or request

Comments

@jawaff
Copy link

jawaff commented Nov 26, 2024

Describe the feature

This stems from a concern that the provided interfaces prevent reuse of what should be immutable objects in memory. For context, to load up a SchemaRepository's lookup table, we need to read in our schema files and then run them through a dereference(). The OpenAPIContract class does that alongside some validation in its from() function, which is really nice.

To explain the problem, now suppose that I have multiple open api files and thus need multiple OpenAPIContracts that produce routers that are eventually attached as subrouters for the rest server. Each OpenAPIContract will have its own SchemaRepository. Also consider that someone may want a fully hydrated SchemaRepository that I want to expose to a swagger ui or arbitrary http clients (I did that with a handler on some schema route that does the lookup/resolve for the schema and returns it). Every single OpenAPIContract and the separate SchemaRepository for exposing to clients will have duplicate/immutable schemas in memory.

The feature would be to genericize the validation/repo filling (which is filled by calling dereference() on the repo) logic in OpenAPIContract::from, probably moved into the vertx-json-schema library. Then allow a SchemaRepository to be provided to OpenAPIContract::from. That would allow the hydration of a SchemaRepository and then for it to be reused everywhere it is needed.

Use cases

The big use case is the reuse of SchemaRepository's for OpenAPIContracts and also the generalization of a very useful hydration feature for loading schemas into a SchemaRepository. OpenAPIContract is not the only class that can make use of that validation/repo filling logic. The only useful logic I've seen for filling a SchemaRepository's internal lookup map is in OpenAPIContract, but that's not something that should be specific to the openapi library.

Code reuse and saving on memory usage and startup time are the real benefits. In my eyes I would say that this is necessary polish.

Contribution

Who should implement this feature ? are you volunteering for implementing this feature or
do you know that is able and willing implement this feature ?

@jawaff jawaff added the enhancement New feature or request label Nov 26, 2024
@pk-work
Copy link
Contributor

pk-work commented Dec 25, 2024

Hi @jawaff thanks for bringing this up. Did I understand it correct, that you would like to create one SchemaRepository and reuse it in multiple instances of OpenAPIContract?

Maybe you can instantiate OpenAPIContractImpl by yourself and simply pass your SchemaRepository. Would this solve your problem? Of course this isn't a public API, but at the moment I don't see anything that would make this constructor deprecated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants