GraphQLBundle
GraphQLBundle copied to clipboard
overblog
Add Apollo Federation Support
| Q | A |
|---|---|
| Feature request? | yes |
Context
Apollo Federation is the Apollo Platform's solution to creating a unified data graph that has an implementation split across multiple GraphQL services. It would be great if we could hook into this with the GraphQLBundle to take advantage of splitting a single graph across multiple teams.
Here's my current usecase:
- I have two GraphQLBundle servers with two different schemas (one fairly established, the other one only recently started development).
- These two graph schemas should belong to the same Graph (the client consuming the new channel will be consuming information from the original schema as well)
- Currently, we will likely either have to resort to one of the following options
- Have the client manage two different Graphs (far from ideal)
- Do schema stiching (deprecated in favor of federation)
To implement this, Apollo provides a federation spec for adding federation support in non-apollo servers.
@dbartel-br this seem to be a good feature to implement in the bundle. Do you want to work on this feature, I can follow an give helps if needed.
This issue seems to be inactive for quite some time now, so I've closed it. If you feel this issue deserves some attention feel free to reopen it.
@dbartel-br Did you manage to get anywhere with implementing federation into the bundle?
@mcg-web I've managed to make a library on top of WebOnyx/graphql-php that implements federation: https://github.com/pascaldevink/php-graphql-federation It is a very first version and not optimised, but it shows it's possible. Can you point me in a direction as to where to start implementing it in this bundle? I've seen the SchemaExtensionInterface, but there are no good examples or documentation on how to use it, if that is the right start at all.
Hey Everyone!
@mcg-web I was just about to ask a question about this and found this issue. I was working on trying to implement @pascaldevink library into the service. Although I'm not sure given the way the bundle works with TypeResolving if that would be able to be used. Seeing how ive found this and it seems to be a feature that others would like, I am going to keep pushing ahead trying to figure out how to get it working. If someone else is working on this or already completed it please let me know! I'll post any updates here
So working through this a bit and I don't think given the dynamic type resolving that we can go about doing something like @pascaldevink library. That library requires you to parse the entire graph every request and the bundle doesn't do that. So I think for the _Entity union im going to start by just making that something that the users need to define themselves.
I am also having a bit of a problem figuring out how to use directives. @mcg-web if you have any pointers for this that would be great. Thanks!
@Tyler-Gauch as far as i have gone, we first need to enable directives on the bundle. That means we will need to enhance Overblog\GraphQLBundle\Config\Parser\GraphQL\ASTConverter\DirectiveNode to support all kind of directives. @mcg-web any insight over what would be the difficulty into implementing this?
Also, Overblog\GraphQLBundle\Config\Parser\GraphqlParser needs directiveDefinition added as a constant, so we can create the cached type.
We also need to add support for extend keyword, that will create the cached type, or add the fields if the object already exists.
This is a fork i did, its not yet finished. https://github.com/lolaent/GraphQLBundle/tree/objectExtension
@serbanbjd nice! Any idea on how much work is still left to finish this as a PR?
@serbanbjd directive was not implemented because no one seems to have the need for so far. We can implement this in 1.0@dev.
@serbanbjd nice! Any idea on how much work is still left to finish this as a PR?
Well the most important work now is to pass the directives defined in the SDL into webonyx's graphql engine. We also need to be able to define directives in yaml, just like types. Also we need to do validation on the directive's parameters. So we have a few things to do before this is complete :)
