Matt Bessey, a Principal Engineer and Software Architect, shares his frustrations with GraphQL after six years of experience. He discusses the complexities of GraphQL, including its security vulnerabilities and performance issues compared to traditional REST APIs. The conversation highlights the nuances of authorization in GraphQL and the risks associated with query parsing. Bessey also explores the future of API design, advocating for a user-centric approach and critiquing the trend towards superficial programming education.
Read more
AI Summary
Highlights
AI Chapters
Episode notes
auto_awesome
Podcast summary created with Snipd AI
Quick takeaways
GraphQL, despite its ability to minimize over-fetching and under-fetching, introduces significant incidental complexity and security challenges for backend engineers.
The discussion highlights OpenAPI 3.0+ as a favorable alternative to GraphQL, providing a simpler, more manageable structure for API design and security.
Deep dives
Introduction to GraphQL and Its Origin
GraphQL is an innovative query language for APIs created by Facebook to minimize issues of overfetching and underfetching common with traditional REST APIs. It allows clients to request exactly the information they need from a single endpoint, thereby enhancing efficiency in data retrieval. However, the technology comes with its own complexities and challenges for backend developers, particularly regarding performance and security. Matt Bessie, a principal engineer, and software architect, articulates these frustrations in his viral blog post that critiques GraphQL and its practical limitations based on his six years of experience.
Backend Complexity and Security Challenges
One significant drawback of GraphQL emphasized by Matt is its incidental complexity for backend engineers. The intricacies of crafting performant GraphQL queries can lead to performance degradation without any changes to the backend code, especially as client requirements evolve. Additionally, security issues are prevalent with GraphQL, particularly due to its flexible query structure which increases the attack surface. This complexity can manifest in unique vulnerabilities, making it difficult for security measures to keep pace with potential exploits.
Authorization and the Burden on Developers
Implementing authorization in GraphQL poses distinct challenges compared to REST APIs due to its hierarchical data retrieval model. While REST normally requires authorization checks primarily at the endpoint level, GraphQL demands that every field and nested resource must be authorized, creating a cumbersome process for developers. This requirement can lead to significant performance hits, as each authorization check potentially requires database queries, leading to inefficiencies such as the N+1 query problem. Consequently, backend teams often find themselves expending excessive effort on authorization rather than focusing on more critical aspects of API functionality.
Exploring Alternatives to GraphQL
As an alternative to GraphQL, OpenAPI 3.0+ is presented as a more manageable solution that provides a robust structure for API design without the complexities of query languages. OpenAPI maintains the advantages of strong typing and client generation while simplifying security and performance considerations for backend engineers. Emphasizing clear communication between frontend and backend teams can also alleviate some of the issues observed with GraphQL, as both sides can collaborate efficiently on newly introduced data features. Ultimately, while GraphQL brought significant benefits to API development, its difficulties have led teams to reconsider its usefulness, turning toward other methodologies that offer greater simplicity and security.
GraphQL is an open-source query language for APIs and a runtime for executing those queries. It was developed by Facebook to address the problem of over-fetching or under-fetching data, which is a common issue with traditional REST APIs.
Matt Bessey is a Principal Engineer and Software Architect. Earlier this year Matt wrote a blog post titled “Why, after 6 years, I’m over GraphQL”. The post put words to many users’ frustrations with the technology, and it went viral on Hacker News.
Matt joins the show today to talk about GraphQL, the problems it solves, its security vulnerabilities, and why it might not be a good fit for backend engineering today.
Gregor Vand is a security-focused technologist, and is the founder and CTO of Mailpass. Previously, Gregor was a CTO across cybersecurity, cyber insurance and general software engineering companies. He has been based in Asia Pacific for almost a decade and can be found via his profile at vand.hk.