Many developers are moving over from legacy REST APIs to GraphQL APIs. Why is this, and where do they excel? We had a conversation with Eitan Joffe, Chief Technology Officer and co-founder of Inigo, about open source GraphQL APIs. Learn more about their best practices, use cases, where DevOps teams can improve their GraphQL API security strategies, and more.

devmio: Why exactly has developer popularity for open source GraphQL APIs been growing?

Eitan Joffe: Many enterprise developer teams have spent the last several years increasingly frustrated with the shortcomings of legacy REST APIs. But as developers have learned more about GraphQL — the open source query language for APIs initially developed by Facebook — it’s been a change many teams have eagerly made. The transformative speed and simplicity that GraphQL brings to their dev processes, and how it empowers them to create faster and more stable applications that directly control their own data, has led to accelerating adoption. We’re also seeing more and more GraphQL-native organizations and projects emerge. In practice, many teams adopt GraphQL when a team member who had used it before brings it in to overcome productivity or developer experience pain points.

Compared to REST, though, GraphQL is a significant upgrade in terms of its flexibility, scalability, productivity, and developer ease of use. GraphQL also enables a better interface between frontend and backend developers. Backend developers no longer need to write specific APIs for each frontend view because creating a GraphQL schema makes it possible to place many different frontend views on top of the same backend API. This clear separation enables much more rapid frontend and backend development cycles.

Those advantages are making GraphQL a foundational component of API modernization efforts; whereas fewer than 10% of enterprises were using GraphQL APIs in production in 2021, Gartner expects more than half of enterprises will be by 2025.

devmio: What use cases do GraphQL APIs fulfill, and are there any instances where GraphQL APIs are not recommended?

Eitan Joffe: Whereas traditional REST APIs load data via multiple URLs and manage it via a server, GraphQL APIs can gather all needed data in a single request. Applications, therefore, directly control their data without needing server connectivity. Because of this, GraphQL APIs better serve any use case that benefits from better performance even on slow networks, greater flexibility and scalability, and faster time-to-market—which is to say, most of them.

GraphQL APIs are also a great fit for data-rich applications with complex models. For applications that have very few transactional-type APIs, the benefits of using GraphQL are diminished.

Streaming data is an example where GraphQL is not a good fit. That said, the main scenario where I’d recommend against GraphQL adoption is if an organization doesn’t have the security visibility, access controls, and appropriate protections to bring in GraphQL safely. An effective GraphQL deployment must include dedicated tooling and, ideally, a holistic commitment to security from day one. Once those conditions are met, teams can much more confidently modernize and scale with GraphQL.

Backend developers no longer need to write specific APIs for each frontend view because creating a GraphQL schema makes it possible to place many different frontend views on top of the same backend API.

devmio: How does the developer-led GraphQL movement resemble the adoption path Kubernetes took a few years ago?

Eitan Joffe: It’s an interesting parallel. Kubernetes became the ubiquitous container orchestration platform as quickly as it did because developers demanded the flexibility it provides. GraphQL’s trajectory tells a similar story, with developers pressing for GraphQL adoption to modernize and replace the experience of using REST APIs. It’s about making their workdays easier and more efficient.

Market shifts and competitive pressures have also been behind both Kubernetes and GraphQL adoption. With API use growing and the need to share API data and functionality with third-party developers increasing, GraphQL is simply better suited to the needs of modern API activity, just as Kubernetes is best suited to its role.

While GrpahQl is still fairly new, we’re already seeing a shift from developer adoption to production-ready enterprise implementations. And while there are many developer tools for GraphQL, organizations are just now starting to focus on how they’ll effectively secure, control, and manage GraphQL APIs in production—and at scale.

devmio: How significant of an issue is API security (GraphQL or otherwise), what's at risk, and whose responsibility is it?

Eitan Joffe: API security is already a big issue, but it will only get bigger as API ecosystems scale. A recent Salt Labs report found that API attacks have increased 681% in the past year alone. In that same report, 95% of enterprises had experienced a security incident in their production APIs. It’s best just to assume that your APIs are always under attack and have the right plan in place to mitigate that.

Yet as teams rush to introduce new API connectivity and accelerate application development lifecycles, API security is too often an afterthought. For attackers, APIs are a bountiful, ever-expanding attack vector for infiltrating enterprise systems and exposing sensitive data. To address this issue, organizations must—must—implement the most current API security best practices. Ideally, they have these processes in place from the first day they implement GraphQL, but the next best time is now.

With GraphQL in particular, security responsibilities are shared between security, DevOps, and developer teams themselves. GraphQL’s freeform nature introduces new attack surfaces that must be addressed. While direct security responsibilities may be unfamiliar to many developers, GraphQL puts many access control and operations functions squarely in their court. Success requires that developers embrace this security role.

API security is too often an afterthought. For attackers, APIs are a bountiful, ever-expanding attack vector for infiltrating enterprise systems and exposing sensitive data.

devmio: Where do developers and DevOps teams tend to fall short in their GraphQL API security strategies?

Eitan Joffe: In that aforementioned Salt Labs report, 34% of enterprises confessed to having no API security strategy whatsoever. Zero. Also scary: 85% said their current tools couldn’t effectively stop API attacks. That number is somewhat expected, as traditional security protections cannot prevent attacks that hide within complex API business logic (and many enterprises have been trying to do just that). For example, attackers can use malicious clients to overwhelm API registration endpoints, make frequent login attempts, leverage account enumeration to expose user information, and tamper with other parameters to their advantage.

GraphQL traffic and issues often go undetected due to a dearth of proper security tools. That responsibility is shared between the backend, platform, and compliance teams. In short, developers and DevOps struggle when they lack a thoughtful and prioritized API security strategy, as well as appropriate tooling.

devmio: What are three best practices developers can do today to harden their API security?

Eitan Joffe: First, implement a comprehensive API security strategy that employs tightly-integrated schema-based and database access controls, supported by rate limiting and other data scraping protections. Developers need to be equipped with appropriate CI/CD tooling to create and manage code-based access controls without GraphQL’s dynamic schema causing them to make errors.

Next, develop a contextual understanding of client API requests and responses to recognize appropriate business logic behavior and attack surface vulnerabilities. Developers must educate themselves about GraphQL’s particular attack paradigm. Use tools to support and automate this understanding, and achieve timely threat recognition and mitigation.

Lastly, high-scale GraphQL environments should adopt a security federated lens that allows teams to monitor and secure API endpoints at the organizational level. Leveraging strategies specifically designed for GraphQL security can speed up the roadmap toward achieving effective safeguards. Also, standard web application firewalls and traditional gateways lose track of GraphQL usage and create a blind spot—they mainly focus on the HTTP layer.