What Experienced Teams Want You to Know about Migrating to GraphQL
This article is the second in a three-part series:
- Introduction: “Introducing the GraphQL Survey Series: Insight from Successful GraphQL Adopters”
- Part 1: “Why Companies are Adopting GraphQL”
- Part 2: “What Experienced Teams Want You to Know about Migrating to GraphQL”
- 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?
Engineer: 100+ Team Size
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!
Senior Software Engineer: Unknown Team Size
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.
Senior Software Engineer: 10–50 Team Size
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.
Software Engineer: 1–10 Team Size
Research and understand resolvers before moving to GraphQL
Software Engineer: 100+ Team Size
Understand the technology choices you make when using GraphQL. If using something like Apollo, get to know it’s in and outs.
Head of Backend: 1–10 Team Size
Learn GraphQL on a greenfield project and adapt your way of thinking. Do not try to apply previous patterns/models on GraphQL
Head of Technology: Unknown Team Size
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.
CEO & Cofounder: 1–10 Team Size
Strategize a plan to move your infrastructure incrementally over to graphql
Unknown Title: 50–100 Team Size
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.
Unknown Title: 100+ Team Size
Build it for the product not for the data source
Software Developer: 50–100 Team Size
Remember that GraphQL is a very client-focused protocol, and is built around high latency connections. It’s built for frontends, not backends.
Suggestions:
● 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.
Staff Software Engineer: 50–100 Team Size
Get everyone involved.
Invest in tooling
CTO: 1–10 Team Size
Look into best practices and do some demo projects to have a nice insight into how GraphQL works.
CTO: 1–10 Team Size
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
Front End Tech Lead: 1–10 Team Size
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.
Final Thoughts
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
