-
Notifications
You must be signed in to change notification settings - Fork 73
Extending Graphback to support various use cases outside the core package #635
Comments
TL;DR We are trying to make Graphback work exactly how GraphQL-Code-Generator works. This is step 2 to make Graphback work like Codegen does. |
Would types marked as "model" represent database tables and non-model be used for non-db types?
So with this the user could remove the
graphql/graphql-js#869 (comment) - We will have to see if this works for us in practice - it looks like
This is fine as performance will only be sacrificed at generation phase and won't affect application performance.
Did you forget to finish this?
If plugin definition order in config matters this could get really messy and difficult for the end user to configure.
If every plugin depends on the generated schema then should the schema generation phase happen outside (before) the plugin chain?
I like this. Would we also migrate some
|
Yes. This will allow us to introduce rest annotations and handlers much easier :D
Graphback will be the ultimate place that joins them all into a single element.
We going to use graphql-tools for merging and printing. Example:
For runtime cases, it will incur a slower application start.
We need to clasify db annotations that can affect more than just db and move them under some common namespace or we can use some db ones in other generators |
Yes. That is my current focus to see what are the challenges of that approach and to validate it on the top level.
End users will not need to configure it. This is for contributors wanting to bring their own plugins etc. We will have graphback giving opiniated version of it. They will not depend on each other. They will just be able to add things to the schema. This is not new idea - works pretty much like: https://aws-amplify.github.io/docs/cli-toolchain/graphql Transform will:
|
Implemented and available on master. See #675 |
Motivation
Currently to make a change in graphback users need to assses and change elements in Graphback core that might or might not break the entire ecosystem of plugins.
We have done some separation of concerns for architecture but overall customization and maintenance is not easy as we initially anticipated. That is why we need to come up with the right format and document it properly. At the moment we cannot effectively provide solutions for various use cases without including them in the core.
Suggested changes
Instead of parsing model and passing customized objects to the entire ecosystem of plugins we should pass generated schema to every plugin itself.
This will allow users to add their own directives and annotations and allow customization cases that the core team never anticipated.
Instead of assuming that every Type needs CRUD resolvers developers can simply mark types in their schema as model. This approach will allow better support for various graphql patterns where developers need to exclude lots of types etc.
Document architecture of the plugins and describe every plugin similar to graphql-code-generator
Use GraphQL Config for each plugin separately
https://graphql-config.com/docs/introduction
Graphback package as an opinionated manager for all available plugins and their options.
Working with so many packages will be really hard. We need to make things easy by integrating them along with graphql config to minimize the amount of code that is needed and also simplify cli integration
Schema generation should utilize print schema and merge the CRUD model with existing schema instead of rebuilding schema from scratch.
We are going to sacrifice performance and visit every node in the schema for each plugin.
We can reuse visitors from the core and common annotation processors.
Each individual plugin can also
Important change each plugin will get full schema but it can also append/merge stuff and modify schema. The order of the plugins will matter. For example, we can have plugin that will remove annotations in the resulting schema as last step etc. Each plugin will return schema instance that will need to be passed to the next step (this is different to how graphql-code-generator works)
Areas to focus on
Investigate the common set of the annotations that are currently in db namespace that should be shared across the plugins
@craicoverflow
Use generated schema as an input source for every plugin.
One plugin at the time.
@wtrocki
Introduce model annotation. Migrate crud annotations into a single model annotations for simplicity. Investigate how model annotation will work with relationships.
@wtrocki
Introduce GraphQL Config in Graphback
Refactor schema plugin to print schema instead of the building using core
@wtrocki
Replace core with the common set of the visitors that can be reused across the plugins
Investigate and test the relationship models
Interfaces/Scalar support
Add basic schema validation for generated schema
Reevaluate support for custom methods and out of the box queries
@wtrocki
Let's create individual issues once we get agreement on this approach
The text was updated successfully, but these errors were encountered: