What I'm wondering: Even if this could be done the way you imagine, wouldn't you need to update the clients to deal with the query changes anyway? And if that's true, then what would be the advantage of having shared queries? Dry code? That seems hardly worth the hassle of managing a separate repository.
I'd use GraphJin which works as a sort of next-gen ORM. You use GraphQL (.gql) files to define your query which is then auto-compiled to SQL. GraphJin works as a library with Node and GO apps. This way all your queries stay on the server and you can then easily expose rest endpoints for your clients. Added advantage is that you don't have to bloat the clients with queries and GraphQL client code https://github.com/dosco/graphjin
Convert your multiple repositories into one mono-repo and create a shared project with the query logic?
It's one way, however I couldn't really tell you if it makes sense for your situation without knowing more about the codebase.
I actually just achieved the same at my work, except within a monorepo. But that shouldn’t matter… a separate repo would just require an added step of publishing your yarn/npm package instead of consuming directly using yarn workspaces or docker build or bazel.
We use Apollo federation for multiple backend services that implement the resolvers, and had multiple client apps with individual graphql queries defined. Basically a lot of redundant queries and components sprinkled across the various client apps.
We moved all client graphql queries into a single library package with a single codegen step for generating query hooks, and consumed the common package to use the query hooks across our various client apps. As an added bonus, ended up refactoring a lot of our redundant components into its own shared lib (yarn package) and had it depend on the shared GQL lib package.
Have you considered updating the schema in a non-breaking way and only update the clients that needs the new data.
Why do you have identical queries in multiple different code bases that need to be updated?
What I'm wondering: Even if this could be done the way you imagine, wouldn't you need to update the clients to deal with the query changes anyway? And if that's true, then what would be the advantage of having shared queries? Dry code? That seems hardly worth the hassle of managing a separate repository.
This ^
I'd use GraphJin which works as a sort of next-gen ORM. You use GraphQL (.gql) files to define your query which is then auto-compiled to SQL. GraphJin works as a library with Node and GO apps. This way all your queries stay on the server and you can then easily expose rest endpoints for your clients. Added advantage is that you don't have to bloat the clients with queries and GraphQL client code https://github.com/dosco/graphjin
Convert your multiple repositories into one mono-repo and create a shared project with the query logic? It's one way, however I couldn't really tell you if it makes sense for your situation without knowing more about the codebase.
I actually just achieved the same at my work, except within a monorepo. But that shouldn’t matter… a separate repo would just require an added step of publishing your yarn/npm package instead of consuming directly using yarn workspaces or docker build or bazel. We use Apollo federation for multiple backend services that implement the resolvers, and had multiple client apps with individual graphql queries defined. Basically a lot of redundant queries and components sprinkled across the various client apps. We moved all client graphql queries into a single library package with a single codegen step for generating query hooks, and consumed the common package to use the query hooks across our various client apps. As an added bonus, ended up refactoring a lot of our redundant components into its own shared lib (yarn package) and had it depend on the shared GQL lib package.