graphql-dotnet
graphql-dotnet copied to clipboard
graphql-dotnet
How to implement federated schemas?
First of all, thanks for the initial implementation for federated schemas.
Summary
I have a question about how to implement federated schemas with the graphql-dotnet package. I saw a small example in the PR https://github.com/graphql-dotnet/graphql-dotnet/pull/1233 but I'm not sure how to implement this in a GraphType codebase.
Relevant information
I tried it with this approach, but I have no clue how to use it? There is a For() which can be used to reference a type, but what type do I need to pass?
public class AccountsFederatedSchema : FederatedSchema { }
Environment (if relevant)
Package versions:
<PackageReference Include="GraphQL" Version="3.0.0-preview-1268" />
<PackageReference Include="GraphQL.Server.Transports.AspNetCore" Version="3.5.0-alpha0027" />
<PackageReference Include="GraphQL.Server.Ui.Playground" Version="3.2.0" />
Could you provide an example how to use the federated schemas? Thanks!
Seems like at moment it will not work for code first aproach (aka graphtype first) wondering for maintainers perspective of view what will be a good decision here, to make it easier in future to migrate things, lets imagine that we wish to start new project with few entities, we wish to split them upfront into different services and combine altogether in a gateway, e.g.:
At moment we can not do it and there is few posible workarounds
- easy to start from dotnet perspective (no graphql and new tech here)
- will be harder to make both dotnet and node schemas in sync
- will be harder to have a bullet prof ci/cd
- unnecessary layer of rest
- in future node wrapper can be removed and dotnet graphql used instead
- clients wont see change when things will swap
Update: there is a swagger-to-graphql which is capable to create federation compatible graph server on the fly based on existing swagger api which makes this approach little bit easier
- will not have issues with ci/cd
- will be harder for multiple people to work together instead of own services they will work on little monolith
- data may be retrieved directly from different storages - will be harder to split in future
- when we will be able to split everything up all we gonna need from clients to change url from dotnet graphql to gateway
I'm just trying to figure out what other posible options and pros/cons might be here
Hi there, Any news about this ? It's becoming hugely important as schema stitching is depreciated
Unfortunately, I have not watched at the federated schemas yet, I can not advise anything. @joemcbride was the one who added support for federated schemas.
Is there any movement on this front? I'm basically blocked from using graphql-dotnet because of this
Is there any way to help or an amount of sponsoring that would allow for this to happen? I appreciate it's really difficult given you're open source and don't necessarily have the resources
#1669 it will become available here, probably after releasing the new version of graphql-dotnet, gonna need to figure out what has been changed and return to it, but at the moment guys are working on a new version hardly so federation is out of scope
BTW @sungam3r it seems that this ticket may be closed in favor to code first proposal ticket
@SamuelCox If you mean financial sponsorship, I don't think it will have some kind of effect. Mostly two people now work constantly over the project. We work when there is a desire and time. Yes, as always in the OSS our time resources are very scarce and backlog is rather big.
I do not close the tickets that I do not understand. Let it be open until the feature is implemented.
probably after releasing the new version of graphql-dotnet, gonna need to figure out what has been changed and return to it, but at the moment guys are working on a new version hardly so federation is out of scope
Already done https://www.nuget.org/packages/GraphQL/
@sungam3r that is awesome news! glad to see that, so probably there is a chance that we might return back to code first approach
