February 26 • 4 Min Read
**Follow us on Twitterto 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:
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](