Replies: 2 comments 3 replies
-
We would love to see the implementation ideas. If you want to do that via PRs then great but if its easy to explain the general approach in words then thats great too. if the PRs are easy to create then that might be a great way - eg put up a non complete PR say as a way to visualise code. But words can work as well. We are planning to add back in "@stream / @defer" back into graphql-java at some point - we had it but it was too early in a spec sense and the spec evolved and then didnt really move anywhere for a long time. So we removed it until the specification firmed up. I think that time of @stream / @defer is coming back as the spec now seems more stable. That said we dont have a planned work item for that yet (graphql-java is volunteer based - not a pure company backed thing) But we would love to see what you have done. |
Beta Was this translation helpful? Give feedback.
-
By all means we would love to see this code. I cant give you a guarantee that we will accept it BUT we would love to see it. Regarding lazy schemas - could you not use SchemaTransformer to make a new schema with the new elements when they change? We would love to see your stream / defer implementation if possible. At least for inspiration on what things you have in place |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I work for a company that has implemented streaming support as well as something we call dynamic schemas. The streaming support is probably self explanatory but I can elaborate if needed.
The dynamic schema support is really lazy loading of schemas/fields at runtime vs loading up all the definitions when you build the GraphQL object. So in short, we build out the fields lazily against a model that we have. This saves a lot of time on startup.
I'm reaching out to see if the maintainers of graphql-java are open to PRs for these features.
Beta Was this translation helpful? Give feedback.
All reactions