Everything that could go wrong with GraphQL and how ...

An opposite (but equally inefficient) problem is under-fetching. This is when the API call doesn’t fetch enough information, so it has to make one or more additional round trips to enrich its data and build the required data model. That’s a lot of wasted bandwidth and resources, not to mention added latency. Plus a lot of complexity for consumers who want to integrate with the API product. … ## OpenTelemetry and GraphQL performance issues There are plenty of use cases for GraphQL, as well as plenty of challenges. One added complexity is that each client can have a different performance profile on their per query basis, depending on how complex the query is. So, while one client could experience amazing performance, another could be facing performance problems. There’s also the N+1 challenge – a commonly recognised problem, where GraphQL’s execution of a separate resolver for each field in a query results in N+1 round trips to the database. OpenTelemetry can help. You can use it to detect N+1 queries. ... That way, you can be aware of these kinds of expensive queries much faster. Other issues that can affect GraphQL performance include cyclic queries (a potential vulnerability for GraphQL APIs, as they can be used for denial-of-service attacks) and very expensive queries (those with both greater depth in terms of nesting levels and with higher complexity). While OpenTelemetry can help with some of these issues, it’s not quite there yet with others – which is why Tyk is adding its voice to OpenTelemetry community discussions.