Skip to content

Instantly share code, notes, and snippets.

Last active November 13, 2023 08:40
Show Gist options
  • Save swalkinshaw/3a33e2d292b60e68fcebe12b62bbb3e2 to your computer and use it in GitHub Desktop.
Save swalkinshaw/3a33e2d292b60e68fcebe12b62bbb3e2 to your computer and use it in GitHub Desktop.
Designing a GraphQL API
Copy link

"follow the same design patterns layed out here" should be "follow the same design patterns laid out here"

Copy link

stephencorwin commented Jul 29, 2018

@swalkinshaw @inbararan I ended up opting for option C and it seems to be working great! I am already storing only the klassUid on the Hero anyway in the database, which means that I can provide this property in addition to the embedded Klass as siblings.

What has been truly great though, is that with only a minor amount of effort, I implemented Apollo's @client directive. If I am doing this optimization anywhere in the client, I can write a client-side resolver which resolves this fragment of the data from a previously cache result. In this case, I have a MetadataProvider which queries all the Klasses ahead of time.

Below are the results of this optimization for a User with 15 Heroes:

Test Name Duration
Vanilla Embed 23918966 (~0.023)
@client directive 1075378 (~0.001)


I think the thing I like most about this approach is that the API still provides both the Klass and User queries separately and any consumer can utilize it as they would expect (embed approach) while the client can keep the same structure and pivot with only adding the @client directive.

Note: obviously, this is a small contrived example, but I believe the more Heroes requested, the more benefit you gain from this optimization.

Copy link

If business decides it needs a new field, does a developer have to go in and program it...everywhere? What I am asking is, for every change in the business, does a developer need to dig into the schema? Couldn't all this be automated in some way?


Copy link

I'm not sure I understand your question @smolinari. You add a field to a type definition. That field then becomes available everywhere that type is being returned. So adding a field only requires adding it in one place.

Copy link

@smolinari You only need to define types on the server, the front-end dev can simply reference the types when writing queries and mutations on the client. Your graphql server is the source of truth.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment