What Experienced Teams Want You to Know about Migrating to GraphQL

Trevor Heath
Feb 26, 2019 · 5 min read

This article is the second in a three-part series:

  1. Introduction: “Introducing the GraphQL Survey Series: Insight from Successful GraphQL Adopters
  2. Part 1: “Why Companies are Adopting GraphQL
  3. Part 2: “What Experienced Teams Want You to Know about Migrating to GraphQL”
  4. Part 3: “How Companies Are Using GraphQL & What They Migrated From

**Follow us on Twitter to get notified when the upcoming articles are published.

In this article, we will share some of the qualitative sentiment we received from our GraphQL survey. Since sometimes it can be hard to paint a full picture without some qualitative feedback, we offered our survey takers the opportunity to share any helpful tips and tricks they learned along their journey.

The following tips and insights come from teams of all sizes. Including responses from engineers at Uber, Houzz, Paypal, Shopify and a bunch more. I will be sharing each quote unedited and tagged by job title and engineering team size.

Some common themes summarized:

  • The importance of schema design focused on the front end’s use case
  • Include everyone on your team in that schema design process
  • Be aware of how your decisions affect the GraphQL API’s performance
  • Tooling is critical and your choices should be tested and researched

The responses - If you were to give another team advice on migrating to GraphQL, what would it be?


Figure out your type safety story, generate types for your components for improved type safety. Start with one endpoint and see how it goes. GraphQL is great!

Schema design is extremely important. The data should be in a format which is easily consumed by the front end without much processing. It might be a good idea to co-locate queries with components to keep component and data responsibilities obvious.

Every query and type which will be stored in the cache must have a unique ID. Mutations and optimistic updates might not work the way you expect if you don’t have them. Be conscious of repeated transactions within the same request.

Consider using something like Prisma to avoid needing to scaffold out all the base CRUD operations all of your base models always end up needing eventually later anyways. Having to build them all yourself is very time consuming. That’s not just a GraphQL thing, but in general it has saved a massive amount of time not needing to implement every pagination and sorting parameter for every new type we add.

Research and understand resolvers before moving to GraphQL

Understand the technology choices you make when using GraphQL. If using something like Apollo, get to know it’s in and outs.

Learn GraphQL on a greenfield project and adapt your way of thinking. Do not try to apply previous patterns/models on GraphQL

Pay great attention to how you model your domain. If you do not want your API to grow out of control, I would recommend paying good attention to how the domain is expressed in terms of a graph.

Choosing a good list pattern (relay-style connections, arrays, etc.) early on is also a good practice, so that it can be consistent throughout the API.

Strategize a plan to move your infrastructure incrementally over to graphql

It’s a great alternative to REST, but if you’re dealing with a large database or multiple microservices, be prepared to use caching or Facebook’s data-loader (open source project) in order to resolve performance issues that GraphQL doesn’t solve out of the box. Primarily the N+1 issue posed the greatest challenge for us.

Build it for the product not for the data source

Remember that GraphQL is a very client-focused protocol, and is built around high latency connections. It’s built for frontends, not backends.


● Remember that the GraphQL schema doesn’t have to directly align to your backend services — it can, and should, expose data in a way that is most convenient to clients.

● Strongly consider letting your frontend teams own the GraphQL schema. After all, they’re the ones interacting with it the most, and have a better idea of how clients would prefer accessing data.

● If you’re in an environment with many internal services, don’t follow the temptation to convert them to GraphQL. Bandwidth is cheap, and the added cognitive load and technical complexity load of GraphQL for service <-> service communication isn’t worth it.

Get everyone involved.

Invest in tooling

Look into best practices and do some demo projects to have a nice insight into how GraphQL works.

It have some performance downsides but stills worth to scalability on the client side.

The C# GraphQL library is completely awesome, one of the best choices that we have made

Experiment with the client libraries you’re going to use a lot beforehand. Also, try to use the opportunity to better apply concepts like domain-driven design and layered architecture.

As you can see GraphQL is viewed as a positive addition to a company’s technical architecture and teams of all sizes have adopted it with tremendous success. However, as with all new conventions, it is important that you grasp the core concepts, keep up with best practices, test your use case and steer away from forcing old methodologies on the new building patterns like GraphQL.

*To learn more about our team at Novvum + GraphQL check us out here: novvum.io/graphql


We are Novvum. A hard-working team of engineers, designers, and tech enthusiasts that love helping companies build leading software products.

Thanks to Kris Yang and Andriana Angelevska

Trevor Heath

Written by

VP of Product Development, Novvum



We are Novvum. A hard-working team of engineers, designers, and tech enthusiasts that love helping companies build leading software products.

Welcome to a place where words matter. On Medium, smart voices and original ideas take center stage - with no ads in sight. Watch
Follow all the topics you care about, and we’ll deliver the best stories for you to your homepage and inbox. Explore
Get unlimited access to the best stories on Medium — and support writers while you’re at it. Just $5/month. Upgrade