But… lol then I wonder, why are the same types coming in from both FQL and GraphQL?
Honestly, though, if you are using a GraphQL client that has any catch built in, then I expect getting data from outside of that system is going to wreck it, or it will be tedious and error prone to keep things in sync. If you’re building things from scratch anyway then maybe not so bad.
So, these comments do not answer your question, but try to avoid encountering the problem altogether.
Leverage UDFs and Custom Resolvers
You can do awesome things with UDFs and customer resolvers. If you have a straight FQL query you are making, there IS a way to add that to your GraphQL schema. And often, you can return types in such a way that you can let the normal GraphQL api take over.
For example, some arbitrary function that compares some things, creates some things, links them in a certain way, and then returns a result of “[OrgMemberLink]”. You could then use the GraphQL api like normal to expand the fields for the returned items.
Maybe you can manage to do this only for those queries that return types in common with GraphQL?
This is really my recommendation. The two following are kinda options. But this is the real one. But you may certainly have a use case that demands you use both FQL and GraphQL separately.
Make your other APIs work with your GraphQL client.
Apollo, for example, could access the FQL through a REST api you create and often inject that into existing GraphQL client.
Like I noted before, I hesitate any more to highlight Apollo stuff, since there’s plenty of other stacks to work with. But this is there.
Other clients I am pretty sure let you add client only resolvers that can fetch and format data, building it into the existing client and cache.
GraphQL Schema Stitching
You can also create a separate GraphQL server that “delegates” the fauna one, and “stitch” the two on the client.
I’m not actually a fan of this one any more. I used “schema stitching” to add cookies to login requests, and clear cookies on logout. It would also be easy enough to provide serverless functions for those two requests and just manage the login state completely separate from all other queries. Note that there is no type overlap here.
Apollo effectively deprecated schema stitching, in favor of Apollo Federation ( oooOOOooo ) lol. Anyway, Fauna GraphQL api is not compatible with Federation, so it’s not an option yet. Somewhere, I could swear Fauna mentioned considering it…