#The GraphQL Survey 2024
GraphQL has gained significant popularity since its introduction in 2015. Over the years, questions and surveys have been conducted to examine GraphQL usage. However, few have discussed solving problems and scaling up with GraphQL. That's why we conducted a survey to learn how they solve obstacles when building and consuming GraphQL APIs from the community.
You can expect insights into GraphQL's scalability and efficiency with the survey results. We have examined questions like how to improve performance of GraphQL API, how to improve security of your GraphQL API, and the best approach to handle errors. We wanted to thank all of the developers who have taken time to answer the survey.
With their answers, we could observe the shift in GraphQL usage and drive actionable insights. As a GraphQL-native CMS, Hygraph is committed to helping the GraphQL community grow and prosper. Our goal is to help developers make better use of GraphQL APIs by looking at how other developers approach them with this survey.
The results are divided into four sections:
Our Partners
commercetools
Formidable
The Guild
Inigo
eBook: The GraphQL Report 2024
Download the eBook to discover GraphQL best practices from prominent GraphQL users based on the survey findings.
#Survey demographics
In this chapter, we will learn about the survey participants based on their development experience, working knowledge of GraphQL, company size, and more.
Where do you currently reside?
How many years of professional development experience do you have?
Graphql experience by development experience
How many employees are there in your company?
#How is GraphQL used?
In this chapter, we look at survey participants' use of GraphQL. Their experience with GraphQL projects, the size of their projects, and how they work with GraphQL
How is your organisation using GraphQL?
How many GraphQL calls do you handle in a month?
How do you work with GraphQL?
#How Developers Build GraphQL APIs
In this chapter, we delved into the practices and preferences of developers building GraphQL, exploring key areas such as API versioning, caching strategies, security measures, schema combination, server implementation, code generation, language usage, and analytics tools.
What measures do you take to improve GraphQL API performance?
“Other“ inputs include
Does your GraphQL API handle authentication and authorization?
What measures do you take to implement auth in your GraphQL API?
What measures do you take to improve GraphQL API security?
“Other“ inputs include
How do you combine schemas?
“Other“ inputs include
Editor's Note
How do you approach caching?
What approach do you take for versioning your GraphQL API?
What approach do you use for creating GraphQL server?
“Other“ inputs include
Do you use code generation on your GraphQL server?
Which language(s) do you use to write your GraphQL servers?
Which framework(s) do you use to write your GraphQL servers?
“Other“ inputs include
What analytics tools do you use to monitor GraphQL usage?
“Other“ inputs include
What transports do you use for GraphQL?
#How Developers consume GraphQL APIs
In this chapter, we delve into questions that shape GraphQL utilization. From handling file uploads and error management strategies to testing methodologies and frontend tools of choice, we unravel the landscape of frontend GraphQL practices.
Do you use Fragments?
“Other“ inputs include
Do you use subscriptions?
How do you handle file uploads?
“Other“ inputs include
Which error handling approach do you use?
“Other“ inputs include
How do you use types errors in the schema?
| Responses |
|---|
| Unions |
I return a standard response that is { success: boolean, errors: CompanyNameErrors[], data: T }. Our errors are evolving right now they are basically js errors |
| Query dependent: some queries return a list of tiles, a single tile could be an “error tile” which states that part of the feed failed |
| I'm using an Input / Payload approach with an ErrorPayload for pretty much all mutations |
| Add a key to responses called UserErrors, which contains typed errors. Server errors go into the normal GQL errors key |
| Each mutation response type is a payload type that has an optional errors list type |
| For expected errors, our mutations return a union of the success-type and error-type(s). For unexpected errors, we use the error field and return null for data |
We wrap all our GraphQL responses in a Response object with an Error attribute that looks like { code: Enum, message: string } |
| We use an error type with a status field and a message field |
| Response objects containing lists of errors |
How do you test your GraphQL APIs?
“Other“ inputs include
Please add the pieces you test in isolation, e.g., resolver, data layer, client, auth
| Responses |
|---|
| Client request |
| Resolvers |
| Datalayer |
| Business logic |
| Auth |
| Plugins |
| React frontend component |
| GRPC of services |
| Domain verticals |
| Services |
| Guards (NestJS) |
What language do you use to consume GraphQL APIs?
“Other“ inputs include
What framework do you use when pulling data from GraphQL APIs?
“Other“ inputs include
Do you measure performance of your GraphQL API?
“Other“ inputs include
How do you measure GraphQL API performance?
Which aspect is important for you, when using GraphQL API?
What is the importance of each of the following on a scale of 1-5 for you, with 5 being the most significant?
Do you use multiple GraphQL endpoints from the same frontend?
Please describe some pain points/feedback when using multiple GraphQL endpoints
“Other“ inputs include
How many (GraphQL) APIs do you consume in your application?
Which client side caching tool/approach do you use?
Recommended reading
Bryan Robinson
Kelly Goetsch
Carlos Kelly
Shahar Binyamin
Learn scale-efficient use of GraphQL
From the GraphQL Report 2024 survey findings and best practices from prominent GraphQL users.