smallrye
Provide support for creating dynamic schema
Provide SPI support to build the schema dynamically using programmatic API instead of static annotations. This allows building of framework that can dynamically build the graphql for DB backend
The underlying graphql-java library provide dynamic generation of the schema
For that you can just use graphql-java directly ? Or if in Quarkus use vertx-graphql (and graphql-java)
using the underlying graphql library means leaving the standards(spec) world. The current microprofile graphql spec does not provide for dynamic generation of schema. A mix of of schema generation - annotation and dynamic - is highly useful. Smallrye being an implementation of the spec can develop the missing spec and contribute it upstream. I observed that the graphql spec have not been updated recently. The graphql spec is not as rich as the REST spec
@smsajid Maybe you want to work on the details? The main question that I have is: when will this code be executed? In the current state of things, the schema is generated statically at build time. Maybe we need some other kind of tooling; something that takes the DB schema and generates MP GraphQL-annotated Java code? What do you think?
@t1 I don't advocate for smallrye to generate the schema from DB. That is a too specific requirement to be implemented in a library/framework. Someone would want to expose mongodb, redis, elasticsearch, etc. as a graphql api. Given these requirements, how can I generate the schema at runtime by reading each of those sources? Currently, as you mentioned, the schema is built at build time. So, annotations is the only approach. So, why not allow the schema to be built/rebuilt at runtime as well with appropriate hooks?
I know it can be done with the underlying graphql libraries. But my main expectation is to stay in the 'specification world' as well for the ability to migrate to a different implementation.
I can completely relate to and appreciate your idea; I also love standards, although they are hard work to get right. I would like to see how this could look in practice. Maybe you could build a PoC using graphql-java, and then look for a good abstraction on top of that, that can serve as the basis for a new API in the MP GraphQL standard.