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:

• Survey demographics
• How is GraphQL used?
• How Developers Build GraphQL APIs
• How Developers consume GraphQL APIs

#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?

We have mixed survey participants from as many as 30+ different countries. Mainly from North America and Europe, other countries include India, Nigeria, Turkey, Brazil, and more.

How many years of professional development experience do you have?

We have a senior developer base. 41.3% of the participants have 10+ years of experience and almost ⅔ of our respondents have more than 5 years of experience.

Graphql experience by development experience

We further explore developers’ years of experience on GraphQL. Given that GraphQL was released in 2015, it is a relatively young API (comparing to RESTful API which released in 2000). It’s unsurprising that 46.1% have worked or studied GraphQL for about 3+ years.

During the notable 'GraphQL boom' happened in 2018, there was a significant push for widespread GraphQL adoption, emphasizing its popularity and relevance in the tech community. However, it is worthwhile to remember that most of our audience will be biased toward GraphQL (since Hygraph is a GraphQL-native CMS).

How many employees are there in your company?

The evenly split answers illustrate that there is no specific developer market for GraphQL.

GraphQL can be used by teams of 5 as well as teams of 1,000.

GraphQL adds value almost anywhere you use it. By building it properly or tying it together with your API in some meaningful way, GraphQL shows its value quickly.

#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?

61.7% of developers use GraphQL actively, which is unsurprising given the participants' demographics, whereas 15.5% are exploring or drawing proof of concept. The shift in APIs in a tech stack requires some time. It could mean GraphQL would be used in production in the near future.

How many GraphQL calls do you handle in a month?

We can see from the chart how the sizes of our respondents’ projects are distributed. A total of 56.3% of respondents use more than 100.000 GraphQL API calls per month, including 28.7% who make more than 1 million calls. For folks who currently have a small-sized project, this eBook can be a helpful reference to see how things can be scaled up.

Additionally, there can be different interpretations of how participants think about the number of requests they make, as they might consider a cached hit a GraphQL request if they're heavily caching.

How do you work with GraphQL?

According to respondents who don't work on both sides, more people consume (26.2%) than build GraphQL APIs (18.9%). This suggests that the results are a representation of Hygraph's community since we are a GraphQL API builder, people using Hygraph tend to consume GraphQL APIs mainly.

#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?

There is good news that 67% of respondents cache in some form. However, we would like to see that number go up since caching is critical. Even so, we understand that caching might be impractical for real-time data projects.

There are many ways of caching GraphQL. As you grow, you'll probably explore all of them. Based on how you work with invalidation, caching methods can be divided into three categories:

Invalidating the cache on any data change: This approach is simple, but it's unsophisticated because every time you change something, the entire cache is lost, which can lead to a bad experience as you scale, but it's still better than nothing.

Invalidating cache based on changes per data type: This can significantly enhance performance as changes increase.

Invalidating the cache per object: It can contribute to more efficient and optimized GraphQL API performance by providing a balance between caching benefits and maintaining data freshness. This is needed as the number of changes increases.

Many GraphQL caching tools, like Stellate, can be instrumental in implementing advanced caching strategies. It offers granular control over caching rules, ensuring optimal performance and up-to-date data delivery.

52,6% of the respondents use client-side query optimization

GraphQL provides the benefit of getting everything in one request for your frontend, which is one of the main advantages of the protocol. 52.6% of applications use client-side query optimization, which often requires giving up this benefit for a RESTful-like approach.

There are also individual inputs that answered “none”. We are curious whether they are the same folks with less project traffic. If you are not taking measures to ensure performance, you will hit some issues when the traffic increases. Developers need to know about these measures and how to react in case production goes down.

There have been individual inputs mentioning DataLoader. This is also a valid consideration since it has become an essential requirement. You should have a DataLoader if you write your own GraphQL server.

As other ways to improve GraphQL API performance, it may be helpful for frontend developers to incorporate pagination, ordering, and filtering, while backend developers may want to consider building such features.

Pagination: 
Implementing effective pagination is like providing users with a single chapter from a large book, making large datasets manageable and user-friendly. This approach improves the user experience and reduces the load on the server by sending data in smaller, more manageable chunks.

Ordering and Filtering: 
These features allow users to sort and access data based on specific criteria. Efficient ordering and filtering improve data retrieval, enabling users to quickly find the information they need. This is akin to an efficient search function in a digital library.

Does your GraphQL API handle authentication and authorization?

Securing your API requires implementing effective authentication and authorization. The survey findings spark discussions on balancing user identity verification and access control in GraphQL APIs.

What measures do you take to implement auth in your GraphQL API?

Most respondents (61.8%) use the simple header/token-based authentication approach. This indicates that they may not have complex authentication requirements yet.

However, as you scale the project, you can consider more sophisticated methods like RBAC (Role-Based Access Control) to create different access levels within an application, ensuring users can access only the data and features appropriate for their role. This enhances security and operational efficiency.

Furthermore, when designing your schema, you can consider field nullability (whether a field can be empty) and error handling (how the system responds to unauthorized access attempts).

What measures do you take to improve GraphQL API security?

Corresponding to what we discussed in the last section, restricting access (52.6%) like RBAC continues to be a big topic. Restricting access and keeping APIs within the rate limits (55.3%) is vital since you want to ensure that only users who have been granted access have access and that they do not send a lot of queries at once, it’s also a great way to prevent DDoS. Even so, rate limits won't be sufficient to protect GraphQL APIs to some extent despite its ease of use.

34.2% of respondents voted for complexity limiting. We believe it should be considered at the same level of importance as rate limiting since without complexity limiting, it can even lead to denial of service attacks.

Although GraphQL makes it easier to build super complex queries, performance issue comes as the price. One of the complaints about GraphQL is that a simple-looking query can become complex and expensive on the backend. If you don’t limit the complexity, you run a risk of allowing somebody who doesn't necessarily know what they're doing to make something dangerous.

How do you combine schemas?

A total of 20.4% of respondents merge data from multiple schemas directly in their code. This would not be recommended since using GraphQL-based methods like Apollo Federation (17.8%) would save you time and money. The other options are mostly code-based, like schema stitching (14.5%) and GraphQL modules (11.8%). 

With multiple APIs, having a service that is easy to use is beneficial. Content Federation is a good approach if you also need to use a CMS for your project. 

There are also cases where it makes sense not to combine schemas. Deciding when to combine schemas and when to keep them separate is crucial for maintaining a clean and effective GraphQL setup.

How do you approach caching?

In general, over a third of respondents use a caching provider built into their work. A quarter of participants (25%) rely on the client to cache the response. While it can be tempting to rely heavily on client-side caching, it’s essential to balance this with server-side options to prevent performance issues, especially on lower-end devices. Otherwise you might pay more without benefiting your customers and product, while also having worse performance.

21.1% rely on their service provider to handle caching. One of the easiest way of caching is to work with GraphQL providers that offer caching on the CDN level since it can significantly improve application performance, reduce latency and server load by caching data closer to the user, akin to having strategically located warehouses for faster delivery. This means saving money, having better performance for customers, and less problems without doing anything yourself.

What approach do you take for versioning your GraphQL API?

52% of respondents don't version their API. It is fine if you are working on smaller APIs or aren't as far along.

This list is a good place to start looking for versioning solutions, and you can use what you need to make versioning easier by going down the list. Utilizing the @deprecated directive (34.2%), for example, helps phase out outdated features. 

A single anti-pattern on the list is maintaining multiple versions of an API (11.2%), which should be avoided since it increases maintenance overhead, causes confusion among developers, and requires detailed documentation to guide users smoothly through the various versions.

The necessity for API versioning often depends on whether the API is public or internal. For public APIs, especially those used by external developers, versioning is crucial to maintain compatibility and provide a smooth transition for consumers when changes occur. In contrast, internal applications may have more flexibility to evolve without strict versioning since they control both the server and client sides, allowing for holistic migrations when needed. While versioning adds discipline even in internal efforts, it becomes imperative for APIs with external dependencies to ensure a seamless experience for consumers during updates or modifications.

What approach do you use for creating GraphQL server?

We wanted to observe how developers design their servers. Despite historical debates, the community acknowledges that the method chosen doesn’t markedly affect GraphQL server effectiveness.

Do you use code generation on your GraphQL server?

52.6% generate types from the GraphQL schema. It’s an appropriate use case since GraphQL is a fully typed query language. If you use TypeScript on the frontend, there are tonnes of benefits to generating types from GraphQL schema to prevent broken shipping. 

However, other great use cases are not being discussed as much, like generating database operations from GraphQL schema, for which we have 19.1%.

If you aren’t using code generation in your GraphQL server (33.6%), you can look at how to do it from our DevRel Tim Benniks’ tutorial on how to use Nuxt 3 with Hygraph and GraphQL, where he demonstrated how to make automatic code generation. 

In GraphQL sometimes there's a repetition and you have to write a schema file to define how your server communicates with the frontend. It's like a manifest of what queries are supported by your GraphQL server. 

There are multiple options for generating schema, it totally depends upon your development style, or how you have been developing with it. I asked this question to find out how people do it, to understand how we can help people create tools that generate things from Hygraph.

Which language(s) do you use to write your GraphQL servers?

GraphQL started out as a language for communicating with frontends where most people write JavaScript or TypeScript, and Facebook has written the GraphQL framework in JavaScript.

Unsurprisingly, 77.6% of respondents use TypeScript/JavaScript. If you don't have specific performance requirements, or an existing huge codebase in some language, TypeScript works really well because of all the tools around it. Furthermore, the reference implementation of GraphQL is in TypeScript/JavaScript. Things usually happens in the TypeScript ecosystem, and then trickles down to other languages.

However, this does not mean other communities cannot benefit from it. GraphQL is easy to work with in other languages, as the results suggest. Developers use Go (8.6%), Java/Kotlin (7.9%), c#/.Net (6.6%), and other languages because GraphQL works well to communicate between servers and applications.

Which framework(s) do you use to write your GraphQL servers?

TypeScript/JavaScript-based frameworks are the most popular, like Apollo GraphQL (63.2%) and graphql-yoga (13.8%). A great deal of praise has been given to GraphQL-yoga for its ease of use.

As we've seen in the last question, developers also use frameworks based on other languages, including 5.9% gqlgen (Go), 5.3% Hot Chocolate (C#), 3.9% GraphQL Spring Boot (Kotlin/Java), and others.

It's worth noting that there's a single input mentioned Postgraphile which is not a language but a database. It means they do not use any language in their backend, but only integrate GraphQL with the database, which is an out-of-the-box use of GraphQL.

What analytics tools do you use to monitor GraphQL usage?

The answer to this question depends on the size of the projects being discussed. You don't necessarily need analytics if your API is small or internal (43.4%). 

On the other hand, if you get a performance issue without a monitoring tool, it's difficult to identify what's happening. GraphQL monitoring tools can combat the argument about GraphQL being more difficult to use than REST as monitoring takes lots of complexity out of it. If you have a proper monitoring setup, you can see what queries are running, which are slow, which are the expensive ones, and so on.

You have 2 ways of monitoring GraphQL usage.

One is doing it on a request basis like how a specific query is performing as a whole. We use this a lot at Hygraph because the other approach isn't viable for us.

Or you can do field-level monitoring. Unlike traditional REST-like monitoring, field-level insights give a more detailed understanding of API performance, allowing developers to pinpoint and address specific issues effectively.

The way of monitoring is depending on how you build your server. For the basic approach, it's helpful to know that you have the monitoring tool from Apollo Studio (26.3%) if you are already building with it. Other options include GraphQL Hive (4.6%) and New Relic. These tools provide comprehensive monitoring and analytics capabilities, helping developers quickly identify and resolve issues, ensuring optimal GraphQL API performance.

If the GraphQL owner of the plot doesn't have full control or insight on how their graph is being used, it's going to be very challenging for them to continue with their GraphQL adoption journey to move for acceleration and insights. 

What transports do you use for GraphQL?

Our intention was to learn developers’ transport for GraphQL, which comes as no surprise that most people make HTTP requests (92.1%).

#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?

62.6% of developers are using fragments. You should use it if you're using similar queries over and over since it's an easy way to use the same thing repeatedly.

Do you use subscriptions?

34% is a decent number since subscription is a new approach to improving GraphQL API efficiency. When introducing a subscription, it's a good stage in your GraphQL adoption.

How do you handle file uploads?

40% of respondents don't need to handle file uploads, and 33% handle them outside of GraphQL. The fact that there is no standard to handle file uploads inside GraphQL is notable, as previously existing standards are becoming less relevant.

Which error handling approach do you use?

64.6% of developers rely on the errors field. It's a standard approach. However, there is not much information about what went wrong. Developers can extend errors using the extensions field (20.4%) because then frontend developers will give you more information and help you handle errors faster. 

Error handling is crucial since you'd never want to throw the full HTTP error but instead put it in part of your message. That's what we did at Starbucks and Puma. That way, it also gives us analytics on what went wrong, and which property didn't validate or couldn't resolve.

How do you use types errors in the schema?

In GraphQL, the standard practice is to utilize the "errors" field to communicate issues when something goes wrong. However, an alternative approach is to define custom error types. While these errors are still considered errors internally, they appear as data on the frontend, providing developers with the flexibility to handle errors differently.

The responses we received showcase different strategies. Some create custom error types using unions, while others wrap their GraphQL responses in a "Response" object with a separate "Error" attribute consisting of a code and message. This approach allows for frontend interpretation based on error codes.

Some developers leverage a query-dependent approach, where a list of titles includes error tiles to signify failures in specific parts of the feed. This is useful for scenarios where certain feeds may fail while others succeed, offering a nuanced response to frontend developers.

An Input/Payload approach is adopted for mutations, featuring an "ErrorPayload" for error handling. However, using an error type directly could achieve the same result without introducing an additional layer.

There's also a method involving adding a key called "UserErrors" to responses, containing typed errors. While GraphQL errors are still used, developers insert an extra layer of custom errors within the data, potentially doubling the workload.

While most developers utilize the "errors" field in GraphQL for error handling, those opting for typed errors often introduce additional layers of complexity. This involves creating custom error types within the data, potentially due to specific requirements or limitations faced with standard GraphQL error handling mechanisms.

How do you test your GraphQL APIs?

One common method is through integration tests (35%), often referred to as API acceptance tests. In these tests, developers write queries that simulate what the frontend might send to the server, ensuring that the server responds as expected. These tests validate the end-to-end functionality of the GraphQL server, confirming that the queries produce the desired outcomes.

Another approach involves testing solely on the client side (19.4%). The server is abstracted in this scenario, and responses are mocked based on potential server behaviors. Developers write test code on the client to assess how it handles different scenarios. While this approach is less favorable and might explain the lower number of respondents, it is occasionally employed.

Some developers opt for integration tests focused solely on the server (15.5%). These tests specifically assess how GraphQL requests interact with the server and the server's ability to handle inputs, such as saving data to the database or returning errors. This type of testing excludes the communication layer between the server and the client, concentrating on the server's internal functionality.

While testing the server alone might seem sufficient due to the typed schema in GraphQL, which provides clarity on all possible cases, it is still advisable to occasionally validate client-server communication. This is particularly relevant when custom types or errors are introduced, ensuring these additions function as intended. However, depending on the project's time constraints and the degree of trust in GraphQL's typing system, developers may defer or minimize testing the communication layer.

In essence, the decision to test the client-server communication layer hinges on factors like project priorities, the complexity of custom types, and the level of confidence placed in GraphQL's inherent typing.

Please add the pieces you test in isolation, e.g., resolver, data layer, client, auth

Many developers test resolvers. It's good practice since you want to make sure that the resolver is getting the data from the sources, whether it’s a database or another legacy REST API. 

I've always found that the biggest roadblock is when the resolver doesn't resolve the right data. You need to test the resilience of whatever you're resolving.

What language do you use to consume GraphQL APIs?

GraphQL has a JavaScript/Typescript ecosystem both on the frontend and backend. Corresponding to the answers we’ve got from the question above about the GraphQL server languages, we’ve got similar answers here. Although JavaScript/Typescript (84.4%) is the dominant language here, developers also use C# (3%), PHP (3%), Python (3%), and other languages.

What framework do you use when pulling data from GraphQL APIs?

The top 4 popular frameworks, Next.js (54.5%), React (46.7%), React Native (14.4%), and Gatsby (10.2%) are all React-based. It’s impressive to see how big the React community is. 

Do you measure performance of your GraphQL API?

Over half of developers don't measure GraphQL API performance (60.5%). You need to ensure you're not introducing a performance hit at the expense of a better developer experience.

Not looking at performance is not so helpful for permeability. You will miss information like what sub-graphs are being used more than others. A developer might have changed the schema, or one of the fields that announced caused the aggregation to your server. This indicates you might be missing information to measure SLA and customer experience. 

How do you measure GraphQL API performance?

This list provides methods for measuring the performance of your GraphQL APIs.

When you put a query-based API in production and don’t measure performance, analytics, or error messages, it becomes a pitfall for organizations and might even hurt them as they continue to accelerate GraphQL adoption.

Which aspect is important for you, when using GraphQL API?

A significant portion of respondents emphasized the importance of structured data (31.1%), highlighting a preference for a easily navigable data format when using GraphQL. Ease of use closely followed (28.7%), which indicates the community’s desire for a user-friendly GraphQL API implementation. Type-checking (18.6%) reflects a concern for data integrity and consistency. The responses also indicated a smaller but noteworthy focus on avoiding over-fetching (11.4%) and aggregating requests (7.8%). 

What is the importance of each of the following on a scale of 1-5 for you, with 5 being the most significant?

Performance emerged as a crucial factor, with a steady increase in significance from 4.2% at level 1 to 40.1% at level 5. Features also demonstrated a significant influence, with a substantial 47.9% of participants ranking it at level 5, underlining the emphasis on comprehensive functionality. Usability, while slightly more evenly distributed across the scale, culminated in a notable 50.3% at level 5.

These findings highlight the collective emphasis on a well-performing system, rich feature set, and high usability, showcasing the nuanced priorities within the company when evaluating GraphQL implementations.

Do you use multiple GraphQL endpoints from the same frontend?

More than half of the respondents (65.9%) are not using multiple GraphQL endpoints yet. However, if you use multiple GQL endpoints on the frontend (34.1%), we recommend you learn about the federation pattern.

Federation in GraphQL is designed to help developers work with multiple GraphQL endpoints more efficiently. It allows developers to compose a unified schema from multiple sub-schemas, enabling them to query and interact with data across different services seamlessly. Federation simplifies the process of aggregating data from multiple sources and enhances the maintainability and scalability of GraphQL architectures by promoting a modular and distributed approach.

Please describe some pain points/feedback when using multiple GraphQL endpoints

The most frequently mentioned concern is the need to handle multiple API calls (39.5%), which can lead to increased complexity and potential performance issues. Overfetching data (18%), where unnecessary information is retrieved, and overnesting (16.2%), involving excessively nested queries, are also noted pain points, highlighting the importance of optimizing queries for efficient data retrieval. Rate limiting (14.4%) emerged as another challenge, indicating issues with throttling or restrictions imposed by the GraphQL endpoints.

How many (GraphQL) APIs do you consume in your application?

55% of developers only consume 1 API, and 45% consume more than 1. Most small to medium projects are likely only going to have one API. However, it also depends on the service/state of the survey respondents.

For those working with a single GraphQL API, it's crucial to fully understand and leverage the API's capabilities. On the other hand, those dealing with multiple APIs should focus on maintaining clear communication and consistency between them.

When consuming GraphQL APIs, adopting best practices such as batching requests, optimizing queries to minimize data transfer, and handling errors effectively can enhance the efficiency and performance of the application. Regularly monitoring API usage and staying informed about updates or changes in the APIs can also contribute to a more resilient and adaptable application architecture.

Which client side caching tool/approach do you use?

The results suggest a predominant reliance on Apollo, with 56.3% of respondents choosing this popular tool. Urql (7.2%), Houdini (4.8%), FetchQL (4.2%), Lokka (3%), and Relay (3%) represent a smaller share of the choices. 

For those using Apollo, it's essential to stay updated on the latest features and optimizations it offers to maximize its effectiveness. For users exploring alternatives, Urql and Houdini have gained traction for their lightweight and efficient approaches.

Implementing client-side caching effectively involves understanding the caching strategy, ensuring cache invalidation is handled correctly, and optimizing queries to make the most of caching benefits. Regularly evaluating and updating caching strategies based on evolving application requirements and advancements in GraphQL tooling can contribute to a robust and efficient client-side caching implementation.

GraphQL remains a resilient choice for developers

The popularity of GraphQL is evident, as indicated by Postman's State of API Report. Even with the influx of new technologies, GraphQL stands strong. It is particularly lauded for its adept handling of structured data and seamless ease of use. The evolving landscape witnesses improvements in GraphQL's utility with emerging technologies that simplify its implementation. As developers seek efficient solutions, GraphQL's usability, coupled with advancements in new technologies, positions it as a resilient API choice.

GraphQL as a composability enabler

In the era of growing interest in composable architecture, GraphQL plays a pivotal role. Although composability can be achieved without GraphQL, its distinctive nesting capabilities and simplified complexities significantly streamline the process. Federation techniques further enhance the ease of composing APIs from various sources into a unified API, aligning seamlessly with the industry's evolving focus on enhanced composability. GraphQL ensures a strong emphasis on ergonomic and efficient development, empowering developers to effortlessly achieve intricate data combinations with minimal effort.

#About Hygraph

Hygraph is the first GraphQL-native Headless Content Platform, enabling teams across the world to rapidly build and deliver tomorrow’s multi-channel digital experiences at scale.

It was designed for removing traditional content management pain points by using the power of GraphQL, and take the idea of a Headless CMS to the next level. Hygraph integrates with any frontend technology, such as React, Vue and Svelte.

Get started with Hygraph by creating a free account, learn how our customers are solving real-world problems, gather information about next-generation CMS from our resources or academy, or learn more about the applications of Hygraph.

To discuss how Hygraph can help you transform your digital projects, reach out to us.