Reputation: 145
We are implementing GraphQL and have hundreds of database tables we will need to pull data from.
We want to manage our API in such a way that its easy to traverse and data is broken up into logical groups.
Is there a way to implement something like this:
Group1> Queries
Mutations
Subscriptions
Group2> Queries
Mutations
Subscriptions
...
Or will we need to make separate endpoints for each GraphQL grouping of data?
Upvotes: 0
Views: 377
Reputation: 84807
If it's just a question of aesthetics, I wouldn't really worry about the number of fields on your Query
or Mutation
types. Whether your client teams use GraphiQL and GraphQL Playground to compose their queries (and they really should be using one of those tools), both have auto-completion features that make it simple to pick a specific field from a list of hundreds.
You may be working with specific groups of clients that have specific needs in terms of the data that's visible to them, or in terms of the types of mutations they can perform on the underlying data. In these cases, it may make sense to have separate endpoints with separate schemas, each limited to what a particular group of clients can see and do. If you're using Apollo, you can even start with a base schema and then utilize schema transforms. However, you probably shouldn't create separate endpoints if a particular client is just going to make queries against each endpoint anyway -- that places an undue burden on the client.
You can, of course, simply nest your fields for each root type inside other types. For example:
type Query {
group1: Group1
group2: Group2
}
type Group1 {
foo: Foo
allFoos: [Foo!]!
# other fields
}
type Group2 {
bar: Bar
allBars: [Bar!]!
# other fields
}
This is perfectly fine for your Query type, although I would caution against this kind pattern for mutations. Of course, if you understand the implications, it may be the right solution for your team.
Upvotes: 2