Generate multiple graphs with shared resolvers for common types

[jared-mackey]

Hi,

I am working on a project where I have a lot of overlap between two graphs in terms of types and resolvers but want them as two distinct graphs with overrides in each graph for things that are specific to that one. What would be the best way to structure this?

• I don't think I want federation as it's not really about composing multiple graphs together into one.
• I did try out having two gqlgen.yml files and running generate multiple times with the resolver files that are shared ending up in the same file but they ended up conflicting in some ways.
• I really want a "shared" set of graphql sdls that are exactly the same between the two, including extensions to the root query and mutation types and then specific sets of sdls for the specific additional types and extensions for each graph.
• I also want different servers, which I'll wire up in my router, with their own sets of middlewares and extensions that are specific to those graphs.

Any suggestions on how to set this up? Or maybe suggestions on alternative setups that I should look into?

Thanks so much

[StevenACoffman]

Hey, your question has several possible answers, so it's challenging to provide a specific answer.

There was some discussion about this in #3631 and documentation added specifically https://gqlgen.com/config/#configuring-for-a-big-projects

There's also a discussion about avoiding writing converters: #3086

Note

If the structs have identical fields, you can use Go's built-in struct conversion.

To convert between mostly identical structs, you can use https://github.com/jmattheis/goverter , https://github.com/go-viper/mapstructure or a few other libraries.

However, I'm not sure that entirely answers your question. Can you point out some specific pain points that are still missing?

[jared-mackey]

Maybe this is the wrong approach but I'd love a way to generate multiple graphs from a single CLI invocation in a way that handles conflicts well when they have shared resolvers. Let me give an example.

- graph/
  - schema/
    - admin/
      - user.gqls 
    - shared/
      - common.gqls
      - user.gqls 
    - user/
      - user.gqls 
  - generated/
  - resolvers/
    - shared.user.go
    - user.user.go
    - admin.user.go 

Where you can think of shared types being the User entity which has completely shared fields, but in the admin set of schemas it would have things like a mutation to search other users, delete them, etc and in the user set of schemas it has mutations such as signup, or set profile info.

If we could specify in the config gqlgen.yml something like this

graphs:
   - admin:
     - graph/schema/admin/**/*.gqls
     - graph/schema/shared/**/*.gqls
   - user:
     - graph/schema/user/**/*.gqls
     - graph/schema/shared/**/*.gqls

Where running gqlgen once would generate two distinct sets of graphs that consist of admin/ + shared/ and another with /user/ + shared/. The resolvers for shared fields on the objects, shared mutations, etc would not conflict with each other's extensions of those types.

I've looked at those proposed solutions several times but I'm not sure they really solve this that well. Particularly since they're not structured around the idea of two graphs sharing similar/same resolvers/types.