Why, After 6 Years, I’m Over GraphQL  🔗 **Source:** [Why, After 6 Years, I’m Over GraphQL](https://bessey.dev/blog/2024/05/24/why-im-over-graphql/) > [!note]+ Document Notes > tags: > - GraphQL > - Programming > - Technology > - REST > Author: John Doe > Source: GraphQL Blog > Reference: https://example.com/graphqlblog > date created: {{date:2022-09-27}} {{time:15:30}} > > # Title: Why I Am Moving Away from GraphQL > <!-- deep-read:sections start --> ## Table of Contents: - Summary - Main Content - Attack Surface - Authorisation - Rate Limiting - Query Parsing - Performance - Data Fetching and the N+1 Problem - Authorisation and the N+1 Problem - Coupling - Complexity - Hypotheses - Methodology - Questions - Future Research - Implications - Logical Validity - Conclusion ### References: - [Reference 1: On Security Risks in GraphQL](https://example.com/security-graphql) - [Reference 2: GraphQL Performance Guide](https://example.com/graphql-performance) ## 📝 Summary: The author discusses the evolving perspective on GraphQL, highlighting security and performance concerns, and presents alternative recommendations. ## 📖 Main Content: ### Attack Surface - Exposing a query language to untrusted clients increases the application's attack surface, leading to authorisation vulnerabilities. ### Authorisation - Authorisation against the current user's context is crucial due to fully self-documenting query APIs like GraphQL. ### Rate Limiting - Rate limiting in GraphQL can be challenging due to queries of varying complexities, leading to server overload. ## 📖 References: [List of citations from the article] ## 🗣️ Paraphrase: - Discussing potential solutions for enhancing performance and security in GraphQL-based applications. ## 🧪 Hypotheses: - GraphQL's complexity may hinder adoption by developers seeking simpler alternatives. - Security vulnerabilities in GraphQL APIs could lead to widespread application attacks. ### 📊 Methodology: - Conduct surveys among developers using both GraphQL and REST APIs to assess their experiences and preferences. - Analyze real-world application performance data from GraphQL and REST implementations. ### ❓ Questions: - How can GraphQL improve its security measures to address the growing concern of attack surfaces? - Would shifting to a RESTful architecture resolve the performance issues highlighted in GraphQL? ### 🔮 Future Research: - Investigate the impact of GraphQL's authorisation mechanisms on the overall security of applications. - Explore the correlation between GraphQL complexity and developer productivity. ### 💡 Implications: - Moving away from GraphQL may provide a more straightforward development experience, reducing security and performance overhead. - Suggesting OpenAPI 3.0+ JSON REST APIs as a viable alternative for developers seeking type-safe communication without GraphQL's complexities. ### ✅ Logical validity: - The article presents compelling arguments regarding the security risks and performance challenges posed by GraphQL implementations. - Logical fallacies are limited, with a focus on sound reasoning based on practical experience and observations. ## 🎯 Conclusion: The shift away from GraphQL towards more traditional RESTful APIs may offer developers a simpler, more manageable approach to building secure and performant applications. <!-- deep-read:sections end --> 📄 **Full text:** ![[Full Document Contents/Articles/Why, After 6 Years, I’m Over GraphQL|Why, After 6 Years, I’m Over GraphQL, bessey.dev]] ## Highlights - With GraphQL we cannot assume that all requests are equally hard on the server. There is no limit to how big a query can be. Even in a completely empty schema, the types exposed for [introspection](https://graphql.org/learn/introspection/) are cyclical, so its possible to craft a valid query that returns MBs of JSON: ([View Highlight](https://read.readwise.io/read/01j7ctx90e6ftggsg1wghm3efp)) - A common mitigation[1](https://bessey.dev/blog/2024/05/24/why-im-over-graphql/#fn:1) for this attack is to 1. Estimate the complexity of resolving **every single field in the schema**, and abandon queries that exceed some maximum complexity value 2. Capture the actual complexity of the run query and take it out of bucket of credits that resets at some interval ([View Highlight](https://read.readwise.io/read/01j7cty8r7dd0swvdyhzvbj1zv)) - When it comes to performance in GraphQL people often talk about it’s incompatibility with HTTP caching. For me personally, this has not been an issue. For SaaS applications, data is usually highly user specific and serving stale data is unacceptable, so I have not found myself missing response caches (or the cache invalidation bugs they cause…). ([View Highlight](https://read.readwise.io/read/01j7ctx917tsnydrnam8y0yfex)) - Note: Dive into the latest issue of our newsletter, where we unpack the world of web development! Discover recent updates, community highlights, and new plugins that are making waves in the WordPress ecosystem. Plus, we tackle the complexities of GraphQL, exploring security risks, maintainability challenges, and alternative technologies that may just be the key to a smoother development experience. Check out the full article from bessey.dev [here](#) for a deeper understanding! Here are the top 3 most important takeaways based on your highlights and intent: 🛡️ **Security Considerations** Explore the specific security risks associated with exposing a GraphQL API to untrusted clients. Compare these risks with those of traditional REST APIs to understand the implications for open-source projects and community contributions, ensuring a safer environment for all developers involved. 🔄 **Complexity and Maintainability** Investigate how the complexity of managing data fetching and authorization in GraphQL can impact the overall maintainability and testability of a codebase. Focus on educating contributors about best practices in code management that enhance the sustainability and robustness of open-source projects. 🌐 **Alternative Technologies** Research ways to achieve the advantages of GraphQL, such as type safety and self-documenting APIs, through alternative technologies that minimize complexity. Share findings with the community to foster an inclusive dialogue on best practices and promote informed decision-making among contributors in the WordPress ecosystem. 1. What are the specific security risks associated with exposing a GraphQL API to untrusted clients, and how do they compare to those of traditional REST APIs? 2. How does the complexity of managing data fetching and authorization in GraphQL impact the overall maintainability and testability of a codebase? 3. In what ways can the advantages of GraphQL, such as type safety and self-documenting APIs, be achieved through alternative technologies without incurring the same level of complexity? - if a field resolver hits an external data source such as a DB or HTTP API, and it is nested in a list containing N items, it will do those calls N times. ([View Highlight](https://read.readwise.io/read/01j7ctyjc9mtd9v88xf71953v9)) - Note: 1. What specific challenges and complexities does the author highlight that make GraphQL less favorable compared to REST APIs? 2. In what ways does the author believe that GraphQL's approach to authorization and rate limiting increases the attack surface of an application? 3. How does the author suggest that the evolving tooling for GraphQL might address some of the issues discussed, and does he believe these improvements outweigh the inherent complexities?