devopsy.kinsta.cloud

Tag: GraphQL

GraphQL Documentation Generators: How They Work and Why They Matter
GraphQL is an open source query language developed by Facebook that provides a more efficient, powerful and flexible alternative to traditional REST APIs for fetching and manipulating data over the web. It allows clients to specify the shape and structure of the data they need and receive exactly that, no more and no less.

Unlike REST APIs, which expose fixed endpoints for specific resources, GraphQL enables clients to construct complex queries that describe the exact data they need, with the server returning only that data in response. This allows for more efficient network usage and improved integration with CI/CD pipelines, as changes to the data requirements can be easily made without breaking existing clients.

GraphQL also offers real-time capabilities through subscriptions, allowing clients to receive live updates as data changes on the server and supports a range of programming languages and platforms through a variety of libraries and tools.

What are Documentation Generators?

Documentation generators are tools that automatically create documentation from source code, making it easier for developers and other stakeholders to understand and work with a codebase. These tools parse the source code and extract information about the structure, behavior and dependencies of the code and use this information to generate documentation in various formats, such as HTML, PDF or markdown.

Documentation generators can help improve the quality of code documentation by automating the process and reducing the risk of errors or omissions. They can also save time and effort for developers, as they can quickly generate documentation without having to write it manually.

There are different types of document generation techniques, each with its own advantages and use cases. Let’s discuss some of them:
- Batch generation: A generic technique that involves generating documents in bulk using a set of rules and templates. It’s commonly used for generating reports, invoices and other similar documents that follow a specific format. Batch generation can save time and effort by automating the document creation process and reducing errors.
- Text block correspondence: Involves creating documents based on pre-defined text blocks. These text blocks can be customized and combined to create different types of documents, such as contracts, letters, and proposals. Text block correspondence is commonly used in document assembly tools, which allow users to create documents by selecting the appropriate text blocks and filling in the necessary information.
- Forms: A type of document generation that involves creating web-based forms that users can fill out to generate documents. Forms can be used for a variety of purposes, such as generating applications, registrations and surveys. Forms can be customized to match the specific needs of the organization or business.
- Documentation synthesis: Involves combining data from multiple sources to create comprehensive documentation. This technique is commonly used in software development where documentation needs to be created for different parts of the system. Documentation synthesis can save time and effort by automating the documentation process and ensuring consistency across different parts of the system.
Documentation Generators for GraphQL

Documentation generators for GraphQL work by analyzing the GraphQL schema and generating documentation based on the information in the schema. The GraphQL schema defines the structure of the data and the available operations, and it serves as the basis for generating documentation.

Documentation generators typically follow a similar process:
- Analyze the schema: The documentation generator analyzes the GraphQL schema to identify the available types, fields and operations.
- Generate documentation: Based on the information in the schema, the documentation generator generates documentation in a specific format, such as HTML, markdown or PDF. The documentation typically includes information about the available types, fields and operations, as well as any associated documentation, such as descriptions or examples.
- Include additional information: Some documentation generators may also include additional information, such as query examples, error handling information or performance considerations.
- Update the documentation: The documentation generator can be run periodically to update the documentation based on changes to the GraphQL schema.
Documentation generators for GraphQL are typically designed to be flexible and customizable so that developers can customize the generated documentation to meet their specific needs. For example, developers may be able to customize the format of the documentation, include additional information or exclude certain information.

Documentation Generators for GraphQL: Why They Matter

Documentation generators for GraphQL are important tools for DevOps teams for a number of reasons:
- Efficiency: Documentation generators automate the process of creating and updating documentation for GraphQL APIs. This can save DevOps teams a significant amount of time and effort, particularly when working with large or complex APIs.
- Consistency: Documentation generators can help ensure that documentation is consistent with the GraphQL API and up-to-date. This can help reduce confusion among developers and other stakeholders and improve the overall quality of the documentation.
- Collaboration: Documentation generators can help improve collaboration among DevOps teams by making it easier to share and review documentation. This can help ensure that everyone has access to the most up-to-date information and that documentation is reviewed and approved by all stakeholders.
- Accessibility: Good documentation is essential for developers who are working with GraphQL APIs, and documentation generators can help ensure that documentation is clear, concise, and accessible. This can help reduce the learning curve for new developers and make it easier for developers to understand and work with the API.
- Scalability: Documentation generators can help DevOps teams manage the documentation of large or complex GraphQL APIs, making it easier to keep up with changes and ensure that the documentation is accurate and up-to-date.
Conclusion

In conclusion, by automating the documentation process, documentation generators can save time and effort for developers, reduce the risk of errors and inconsistencies in the documentation and provide a common source of truth for different teams and stakeholders. In addition, documentation generators can help DevOps teams better understand the API, improve collaboration and communication and speed up development cycles.
March 23, 2023
The API Economy: Increasing Potential to Monetize Public APIs

API-first strategies are becoming more commonplace throughout today’s digital strata. APIs connect microservices architectures, power new digital transformations and help development teams avoid reinventing the wheel for common functions. And although most are built to connect internal components, studies indicate a movement toward more externalization and monetization of public APIs.

Over three-fourths of developers now view participating in the API economy as a priority for their organization or plan to prioritize it soon, found Rapid’s newly released 2022 State of APIs report. The survey, which surveyed hundreds of professional developers, also uncovered a modest increase in companies seeking to generate direct revenue from APIs.

Below, we’ll review some intriguing statistics from the Rapid report and consider the major takeaways technology professionals should consider in the year ahead.

API Reliance Increases

Reliance on APIs is rising across the board. Over 62.6% of developers reported relying on them more in 2022 than in 2021. Internal APIs help avoid development duplication and third-party APIs can quickly integrate standard functionality related to payments, messaging, geolocation, data sharing and many more areas. For example, ChatGPT has demonstrated the power of standard APIs to deliver advanced AI/ML to the masses in a programmatic way.

As a result of this interest, the majority of organizations now consider participating in the API economy as a top priority. And as an organization grows larger, its reliance on APIs is likely to increase. A full 40% of the largest companies surveyed reported having more than 250 internal APIs. Nowhere is this more prevalent than in financial services. This finding makes sense, given how APIs can automate payments and underpin the open banking movement.

In terms of who is using APIs, it’s most commonly full-stack or backend developers, the report found. One intriguing factoid is just how much of this work is now dominating developers’ time. Impressively, 65.5% of developers reported spending ten hours or more working with APIs in their job; 14.5% of them said that work takes up all of their time.

Design Trends

In terms of design styles, various standards are used throughout the web development sphere. Yet REST is still king—69.3% of engineers used REST in production. REST is followed by webhooks, WebSockets, AsyncAPI, serverless and FaaS, SOAP, GraphQL, Kafka and gRPC, in descending order of popularity. Across the board, these statistics showed a steady increase from last year.

Of note is that most APIs are built for internal purposes. These often wrap a database or provide open access to an internal microservice. Private use cases are by far the most common approach; according to the report, 75.1% of respondents worked on internal APIs. These findings aligned with other industry reports, such as the Postman State of the API Report, which found that, in 2022, 58% of API initiatives were private.

Third-party APIs (53.9%) and partner-facing services (48.9%) trailed behind internal APIs in popularity. Interestingly, while internal use cases have remained steady, both partner and public-facing strategies have increased since last year. While the growth was a modest 5% for most sectors, partner-facing APIs in some industries grew by nearly 10%.

Spotlight on Monetization

Many still view APIs as operational glue for internal data or connecting partner services. Yet, the possibility of monetization through self-service developer portals shouldn’t be overlooked—countless API-first startups are actively gaining traction and funding. And monetizing this power is seen as a holy grail to some unicorn-chasing VC funds.

Most APIs are purely for in-house internal integrations and are typically not externalized to the outside world for profit. However, this is slowly changing. In fact, 42.6% of organizations are now monetizing APIs, representing an increase of about 5% from 2021.

As one may have guessed, financial services are leaders in monetizing their external APIs. The telecommunications industry is also noticeably active in monetization, too. Furthermore, with size comes increased monetization potential—about half of the companies with a large footprint of ten or more internal or external APIs also monetized them.

API Economy in 2023

Looking to the future, most anticipate more reliance on APIs across sectors — 69.2% expect to rely on APIs even more in 2023. Yet, organizations will have to grapple with particular hurdles in this newfound landscape. For example, a cloud skills gap might bar some groups from realizing the benefits of an API strategy. Other concerns include ungoverned sprawl, authorization concerns, shadow APIs and escalating attacks on public-facing endpoints. Also, some organizations are still determining how to best secure and scale their use of new styles, like GraphQL.

A standards-based approach that applies platform-wide governance will likely be necessary to maintain an efficient yet stable API footprint. To meet these high quality standards, testing is nearly universally applied—92.7% of those surveyed test their APIs or plan to do so. The most common tests ranged from functional testing to integration testing, acceptance testing and performance testing.

The Rapid 2022 State of APIs report received 850 responses from over 100 countries. For more insights, readers can view the complete results here.

January 17, 2023
Why GraphQL Will Reign King

After years of development, GraphQL is set to reign as the go-to API for data fetching. But what is GraphQL? Simply put, it’s a query language that allows you to fetch data from any server, and it’s a noteworthy alternative to the likes of other web service development styles like representational state transfer (REST) and simple object access protocol (SOAP). There are a few reasons why GraphQL will dominate the DevOps world, including its overall efficiency, ability to work with any server and overall ease of use.

Understanding GraphQL

GraphQL is a query language for APIs and a runtime for fulfilling queries with existing data. GraphQL provides a complete and digestible description of the data in an API, gives clients the power to ask for exactly what they need, makes it easier to evolve APIs over time and enables powerful developer tools.

Top Benefits of GraphQL

GraphQL addresses many pain points that often slow down developers, who prioritize adaptability and working quickly and efficiently when building applications.

For one, it is much more flexible than other data query languages, allowing users to specify exactly what data they want and in which format. Other data query languages require users to retrieve all data in a specific format, regardless of whether they actually need the data. That excess, unnecessary intake can cause delays and confusion.

GraphQL’s ease of use is also invaluable, thanks to its simple and intuitive syntax. The language is strongly typed, which means developers can catch errors early on in the development process before code goes into production. This can save much-needed time and money in the long run.

Another benefit is that it can be used to fetch data from multiple sources because it uses a schema that defines the different types of data available. This means if a developer has a field in a schema that could potentially return data from multiple sources, they can specify which source to fetch the data from. Developers don’t get this benefit from other data query languages, which often allow data fetching from only a single source.

Advantages for DevOps Teams Over Other Data Query Languages

As the world of software development continues maturing, so do the tools and technologies DevOps teams use to build and operate their applications.

REST and SOAP are popular web service technologies, but they come with some major drawbacks. Notably, both REST and SOAP rely heavily on URL structures and verbose XML payloads, which makes it difficult to evolve the API without breaking existing clients. And because each endpoint is a unique URL, providing a consistent experience across different parts of the API can be challenging. REST and SOAP are also quite chatty and can make it hard to optimize performance.

In contrast to REST, GraphQL provides a single endpoint for all data requests and is much faster than making many HTTP requests. GraphQL’s declarative query language specifies precisely the data needed – no more, no less – increasing bandwidth and improving performance. Applications can run faster and use fewer resources, which is especially important for mobile apps that need to be lightweight and fast.

Understanding the data is crucial for DevOps teams, and GraphQL allows developers to visualize data in a graph. Teams can see the relationships between different points more easily, leading to better-informed decisions about the best ways to manipulate the data.

The increased efficiency when conducting API calls is also a plus with GraphQL, which helps teams retrieve all information they need with a single API call. Traditional REST APIs often require multiple API calls, mainly because each resource in a REST API is represented by its own unique URL, along with its own set of permissions and data that needs to be retrieved. GraphQL can eliminate this bottleneck.

Overall, dealing with complexity is significantly reduced when developers use GraphQL. When using traditional REST APIs, writing a lot of code to handle different edge cases and error conditions is the norm. But GraphQL streamlines this – much of the complexity can be handled by the server itself, making way for simpler and more maintainable codebases. DevOps teams are also able to decouple their front-end and back-end development efforts by using a schema-based approach. GraphQL enables frontend and backend components to be developed separately without worrying about breaking changes, which means faster development cycles and fewer errors.

The amount of data that organizations need to understand, organize and query will only increase in the coming years. DevOps teams can get ahead of the ongoing data and information onslaught by taking advantage of GraphQL and its unmatched ability to provide an efficient, powerful and flexible API for data fetching and manipulation.

January 10, 2023
5 GraphQL Trends to Watch in 2023

The GraphQL query language had a big year in 2022. We witnessed its increase in production use cases, solving overfetching and underfetching concerns that plagued traditional API integrations. GraphQL can significantly improve usability, aggregate multiple services and optimize how data is ported from system to system.

Yet, GraphQL is also prone to new security concerns. And as attacks on APIs continue to increase and grow in sophistication, an increased security focus will undoubtedly be required to avoid vulnerabilities. The coming year will likely also see architects grappling with their GraphQL maturity as they consider how best to scale its use across an organization and its various stakeholders.

Below, we’ll consider where the tides are flowing for GraphQL in 2023. These forecasts are informed by my coverage in 2022 and reports from within the web development community.

1. Increased Production Use

A full 62.6% of developers reported relying on APIs more in 2022 than they did in 2021, according to RapidAPI’s State of APIs report. As the number of APIs in use expands, we will undoubtedly see more GraphQL examples. GraphQL is popular due to its usability and flexibility which outweighs traditional integration points. Studies showed it is primarily used for exposing internal data, although partner and public use cases are not uncommon.

Representational state transfer (REST) remains a dominant style for modern APIs. According to Postman’s 2022 State of the API report, 89% of developers use REST. GraphQL is in fourth place at 38%, superseded by webhooks (35%) and SOAP (34%). Although usage remains small in comparison, it’s steadily gaining traction and will continue to expand.

2. Unifying Disparate APIs

GraphQL helps expose fields in an easily consumable manner. But it’s also good for aggregating disparate microservices into a unified schema. As such, it is often used as a meta layer that combines multiple REST services, databases and even GraphQL schemas. For the time being, it appears that REST has staying power. And it’s unnecessary to migrate all REST services to GraphQL. Looking to the future, it is more likely to be adopted as a layer on top of existing REST APIs.

Combining multiple backend services under the hood and exposing them in a unified schema creates a more usable, localized interface that frontend developers can work from. In the future, GraphQL might become a meta layer for more organizations, increasing the discovery of internal services and helping teams reuse internal microservices.

3. Supergraphs and Subgraphs

As mentioned above, GraphQL is used not only to combine legacy REST services but also to combine multiple GraphQL schemas. Some call this a graph of graphs—or a supergraph. A supergraph that combines multiple GraphQL schemas would offer unparalleled developer experience in that engineers can access many services from the same endpoint.

However, there’s a downside to centralizing with a unified graph. Different internal teams or partners might only need access to a particular set of functions. Giving the entire schema to every person who walks through the door would be TMI, not to mention a potential security risk that breaks the rule of least privilege. So, the idea of a subgraph has gained traction. A subgraph is an Apollo concept, but the theory could certainly be applied in other implementations. In the future, we’ll likely witness more use cases that use subgraphs to help federate a supergraph across an organization, helping segment a graph to specific stakeholders’ needs.

4. Turning on GraphQL Security Controls

As of 2022, less than half (43.2%) of GraphQL implementations have disabled query introspection. Disabling field suggestions and introspection are means to reduce the risks of public GraphQL exposures. As GraphQL security best practices become more apparent, these numbers will likely become more commonplace. Other security controls, such as implementing query timeouts, query rate limiting and query cost analysis, can also help curb potential malicious behaviors.

As we’ve covered before, security by obscurity is not enough to protect GraphQL. Yet, many native GraphQL security and performance directives go unused. Besides turning on these advanced features, new tooling is coming to market that could harden GraphQL. Security vendors continue to add support for GraphQL, making its protection more accessible for non-security engineers.

5. Managing GraphQL at Scale

GraphQL has arisen in some large production use cases in recent years, helping developer usability at GitHub, boosting productivity at Netflix and aiding Shopify’s API strategy. These case studies proved its usefulness in large enterprises. But how do we effectively scale GraphQL across a massive organization?

The concepts of supergraphs and subgraphs are ways to help scale it across a company. But retaining high performance will also be vital to maintaining an effective, scalable footprint. As such, we will likely continue to see companies optimize how GraphQL is used as it matures. This includes optimizing queries and query depth and applying filtering and rate limiting to fit application demands. Taking measurements of GraphQL response times will be necessary to establish benchmarks to improve over time.

We’re Just Querying the Surface

Above, we’ve only scratched—or queried—the surface of the exciting developments on the horizon for GraphQL in the coming months. There is much more to be said regarding updates to the query language and improvements within the surrounding tooling landscape. Where do you think GraphQL will go in 2023? Let us know in the comments below!

January 10, 2023
GraphQL Vulnerability Analysis: The Top Threats

Publicly available vulnerability data can be a goldmine for insights into how DevOps and DevSecOps teams can prioritize threats and improve security across the pipeline. With this in mind, Inigo recently performed a deep-dive analysis of known vulnerabilities affecting GraphQL components—including GraphQL clients such as Relay and GraphQL servers such as Apollo, Graphene, Ariadne, GitLab Enterprise, Magento and others. Our main data sources for this investigation were the MITRE CVE database and the HackerOne Hacktivity portal.

Analysis and Findings From the MITRE CVE Database

First, a few caveats about the MITRE CVE database. While it’s considered the source of truth for CVEs and the best data source available for understanding these vulnerabilities, it has its limits. Not every vulnerability gets reported, and not every reported vulnerability gets an assigned CVE identifier. Vulnerabilities generally receive a CVE identifier when an impacted software vendor or researcher recognizes a vulnerability and files a CVE request with MITRE. Large software vendors including GitLab, GitHub, Adobe and many more also serve as CVE Numbering Authority (CNA) partners, authorizing them to issue CVE identifiers themselves (often only for the scope of their own software). All this is to say that the MITRE CVE database is a strong data source for our analysis, but it shouldn’t be considered comprehensive.

Inigo started its investigation by searching the MITRA CVE database for the term “GraphQL,” revealing 45 CVE records (at the time of the research) relevant to GraphQL clients, servers, and other components. Interestingly, the first tracked GraphQL vulnerability was CVE-2019-1000011 from 2019: Most likely not the first vulnerability ever discovered in GraphQL software, but the oldest available in this database.

Researchers were curious to know which classes of GraphQL vulnerabilities were most common, and which GraphQL software has the most known CVEs. The following chart displays the results of the analysis answering the first question.

Authorization bypass vulnerabilities are far and away the most common vulnerability class, and a majority representing 54.8% of all GraphQL vulnerabilities. At 16.7%, denial-of-service (DoS) vulnerabilities stand out as the second most common vulnerability class, followed by information disclosure (9.5%), code execution (7.1%), cross-site request forgery (CSRF) (7.1%) and injection (4.8%).

Analysis into which GraphQL software has the most CVEs revealed the following:

To be clear, these findings don’t necessarily speak to how hardened or how safe a particular GraphQL component is. Popular GraphQL servers simply draw more attention and have more eyeballs searching for vulnerabilities, whether they belong to attackers or security personnel. While this fact skews these results, viewing this data at a glance remains interesting.

Analysis and Findings From the HackerOne Vulnerability Database

The HackerOne Hacktivity portal offers a robust database resource that collects information on vulnerabilities as reported by researchers. The analysis looked at public reports of GraphQL vulnerabilities, finding 74 results since 2018.

As the graph shows, identified GraphQL vulnerabilities fell mostly into the authorization class (87%), with DoS (7%) a far second and race condition and session management vulnerabilities each coming in at 2.8%.

Bug bounties offer an interesting and likely influential factor here. Over the 2018-2022 timeframe, bug bounties granted for these vulnerabilities ranged from $250 to more than $20,000. At the same time, authorization vulnerabilities carry a high risk to sensitive data such as personally identifiable information (PII). This drives organizations to place premium bounties on these authorization flaws and motivates security researchers to focus on earning those prizes. Therefore, white-hat hackers will naturally test for authorization flaws first, perhaps leading to their overrepresentation in the data. It’s also important to note that bug bounty programs tend to prohibit testing for DoS vulnerabilities for obvious reasons, possibly reducing their representation here.

Open-Eyed GraphQL Security

For developers, DevOps and security teams tasked with safeguarding GraphQL deployments, the first step is knowing what you’re up against. The findings above should serve as an eye-opener that helps teams to prioritize threats, whether they be authorization, DoS and other classes of GraphQL vulnerabilities. As more and more organizations rush into GraphQL (increasingly migrating from REST APIs), security cannot be put on the back burner. There’s too much at stake, and ensuring the security of GraphQL deployments isn’t nearly as difficult or time-consuming as many teams currently think.

December 1, 2022
Key Findings From the 2022 State of GraphQL Report

GraphQL, the open source query language, has been steadily growing in popularity over the past few years. The language is excellent for frontend development, as it creates a usable interface to fetch precisely the data required for the specific client at hand. You can also use it to aggregate multiple backend services and data sources.

Studies show that the ecosystem around GraphQL is maturing—it has a very global user base and a growing number of tools exist to aid in its adoption. The 2022 State of GraphQL Report found that 61.8% of developers are happy with the overall state of the ecosystem. Yet many native GraphQL features go unused by developers, which suggests there is a wide range of experience levels, from novice to advanced users, working with the technology. This indicates there is plenty of room for growth and knowledge sharing.

Below, I’ll review the key takeaways from the 2022 State of GraphQL Report, considering overall usage data and focusing on the popularity of specific features. We’ll also highlight the state of standard tools used in conjunction with GraphQL to get the job done.

Analyzing Overall Usage Statistics

First off, there is a wide variance in the types of GraphQL APIs in production today, ranging from private to public endpoints. The report found 47.9% of developers use GraphQL for exposing an API intended for a personal website or app, 40.4% use it for private unexposed APIs for internal usage and 19.5% use GraphQL for publicly available APIs intended for third-party developer consumption. This demonstrates its flexibility to cater to multiple scenarios. And while the majority of clients that connect to GraphQL APIs include browsers (62.3%), it’s commonly consumed by other client types such as native mobile apps, other servers and desktop apps.

Previously, we discussed using GraphQL as a composition layer to combine underlying APIs and services. And the report backs up this idea that developers commonly use it to aggregate various data sources: 55.4% of GraphQL APIs hit databases, while 35% consume REST APIs and 14.6% eat other GraphQL endpoints.

In terms of benefits, one strong point is the ability to enforce and validate types for every object in the API. Users find other top benefits to be avoiding overfetching and aggregating requests. Yet, some hurdles still present themselves. These top drawbacks include error handling, performance issues, client-side caching and security woes.

Regarding user base statistics, most users have been working with GraphQL for less than five years. If we look at the type of sector utilizing GraphQL, we see it primarily leveraged in the programming and technology sector. This is followed by e-commerce and retail (16.4%), finance (8.9%) and news, media and blogging (7.2%).

Many Advanced Features Go Unused

Many of the more advanced GraphQL features still go unnoticed by the majority of users. For example, live queries is a feature that helps obtain live data from a GraphQL server, yet only 25% who know about it have used it. Over half of respondents had never heard of @skip, a directive that skips a field based on a value passed to it. Similarly, other directives like @specifiedBy, @defer and @stream also share little-to-no awareness or use.

Analyzing feature usage becomes a bit more serious if we consider the unadopted security and performance features. For example, only 43.2% of respondents have disabled query introspection. Disabling query introspection is a suggested security best practice to limit a hacker’s ability to perform surveillance. But as we’ve previously covered, security by obscurity isn’t enough to protect GraphQL, and an additional security emphasis is often needed.

As most GraphQL APIs are intended for personal or private scenarios, you would think that more security features would be leveraged to limit the threat of introspection and denial-of-service attacks. Yet, the report discovered low usage and awareness of security and performance features like query timeouts, query rate limiting and query cost analysis, all of which could be turned on to curb malicious behaviors.

Tools Used In Conjunction With GraphQL

Developers often seek to combine, aggregate or merge GraphQL schemas from different APIs. To do so, Apollo Federation is the most common solution, used by 22.5% of respondents. This is followed by Schema Stitching (16.9%), GraphQL Modules (4.4%), and GraphQL Mesh (2.9%).

Looking at other technologies used in connection, Next.js is the most popular framework and PostgreSQL is the most common database used. TypeScript and JavaScript comprise the most common languages used to write a GraphQL backend. Developers also use a balanced mix of IDEs to query and test endpoints, including GraphiQL, GraphQL Playground, Postman, Apollo Studio, and Insomnia.

The report also found relatively high usage and retention for tools like the GraphQL Code Generator schema builder, Apollo Client and Apollo Server. The data shows a crowded solution market with Apollo as an industry-leading outlier—many other clients, servers, API generators and schema builders have medium-to-high retention rates yet experience far less use.

Final Thoughts

The 2022 State of GraphQL Report sheds some interesting light on the state of GraphQL, validating a lot of the interest and trends we’ve covered lately on the blog. Of course, there is more to be said about many areas, such as smoothing the transition to GraphQL.

One key finding is the low number of security features being leveraged by developers. A greater emphasis on API security is required to avoid incidents and retain a zero-trust approach. This emphasis is part and parcel of responding to ongoing software supply chain threats and will require more awareness and thought leadership around GraphQL security best practices.

The 2022 State of GraphQL survey ran from June 15, 2022, to July 15, 2022, and collected 3,094 responses. The above analysis only scratched the surface and there are many other insights. For more findings, you can read the full results here.

December 1, 2022
GraphQL: Security by Obscurity Just Isn’t Enough

The debate about how to secure GraphQL rages on. Many organizations are hesitant to adopt GraphQL for public-facing APIs as there is no precise method to handle authorization concerns as of yet. Without a role-based access layer to enable fine-grained permissions for each field (and underlying services that GraphQL might wrap), the query language can be prone to access control issues.

One method to hamper GraphQL access is to turn off introspection features altogether. Some may assume that hackers can’t perform introspection on an endpoint if it’s not visible. But this isn’t entirely true—even though an “internal” endpoint may not be fully documented, any endpoint on the public web can be searched and introspected quite easily by brute-forcing queries or through field suggestions.

I recently met with Karim Rustom, cybersecurity engineer, Escape Technologies. According to Rustom, “making something obscure isn’t enough to make it secure.” Leveraging a single slip-up in access control could be used as a doorway into these systems. Although it’s a best practice to limit introspection, it’s likely not enough to protect production GraphQL endpoints, he said. Below, we’ll consider some common GraphQL threats and alternative solutions to retain a safe GraphQL implementation.

Common GraphQL Threats

Having run thousands of scans on production GraphQL endpoints, Rustom found common trends emerge around GraphQL threats. First, he noticed the potential for denial-of-service attacks to be quite high. GraphQL, by design, is intended to query whatever data the client requires. But sometimes, these queries can return a mountain of data.

If GraphQL owners don’t place a limit on what can be requested in a single query, the platform can easily fall victim to denial-of-service attacks and service interruptions. And limits aren’t only necessary for bulk read-only operations—although GraphQL is primarily used for fetching data, some methods might initiate intense server-side processing, which should be limited in some form. According to Rustom, such data manipulation methods are especially pervasive in FinTech, food delivery or health care-related applications.

Another rampant GraphQL threat lies in access control issues. This comes as little surprise, as access control is ranked as OWASP’s most common web application security risk. Often, when creating new objects or new queries, a developer might forget to add the correct authorization, said Rustom. This can become a huge problem and lead to privilege escalation.

Finally, too many production GraphQL implementations rely on security by obscurity. “Folks think that disabling introspection is a layer of security—we highly stress that it’s not,” said Rustom. He recalled performing penetration testing for a certain client; even though they had disabled introspection, the team was able to fetch ample open paths and discover an unsecured doorway to divulge secret internal knowledge.

Solutions and Best Practices

To avoid some of the vulnerabilities presented above, it’s recommended to first place request limits on overly complex GraphQL calls to prevent denial-of-service attacks. One nuance here that Rustom recommended is to consider request complexity—not in terms of the query size, but the overall processing required. He suggested assigning scores for every query and permutation to help inform the decision about whether or not to process the incoming call.

Furthermore, it’s recommended to disable field suggestions as the feature could be prone to abuse. Using field suggestions, hackers can leak a lot of information to build a partial or complete introspection. These tactics are similar to the word-busting techniques black hats use to perform introspection on REST endpoints.

Although it’s a good practice to limit the possibility of surveillance, hackers can still discover systems and leverage other common vulnerabilities like broken access control. Rustom suggested other tactics, such as luring attackers into a honeypot or logging them into a fake account. Or, creating error messages that are intentionally misleading for a attacker.

To retain a safe GraphQL implementation, organizations can use pre-made free and open source tools to audit their surface area and scan for known vulnerabilities. For example, GraphQL.security quickly scans your GraphQL URL endpoint to discover vulnerabilities. Or, Graphinder can examine a subdomain to discover GraphQL endpoints, which could aid auditing purposes. There’s also middleware that wraps a GraphQL service with additional security, such as GraphQL Armor and GraphQL Shield.

Future of GraphQL in the Market

There appear to be many flavors of GraphQL throughout the market. We’ve seen it emerge as a mechanism to power backend microservices. We’ve also witnessed the technology adopted as a layer to centralize multiple REST services with a more usable data retrieval mechanism for frontend engineers. Some GraphQL endpoints also run on the public web to serve end clients and external partners.

“GraphQL is a beautiful technology, just lacking in security,” said Rustom. And unfortunately, his outlook for API security looks grim—amid political turmoil and economic instabilities in regions like Europe, some companies may seek to cut cybersecurity investments to stay lean. For companies that haven’t yet suffered a breach, security is easy to ditch to slim budgets, but it should remain a priority, said Rustom. “Keep securing GraphQL.”

October 13, 2022
Getting Started With GraphQL APIs

GraphQL, a query language for APIs and a runtime for fulfilling those queries with your existing data, is rapidly growing in popularity. According to the latest State of JavaScript survey report, 44.3% of respondents said they had used GraphQL APIs in 2020 compared to only 5% in 2016. Additionally, many Fortune 500 companies now use GraphQL APIs for their backends in production, while top tech companies like Facebook and GitHub use the API technology to improve their product offerings and boost system performance.

With the ever-changing technology landscape, you might have doubts about adopting GraphQL API for your backend and be unsure how it can improve your current data needs. However, regardless of what language or architecture you are using, GraphQL APIs can help simplify data access, supercharge the product development process, improve application performance and handle complex back-end data scenarios.

One Unified Endpoint For Your Backend

One advantage of GraphQL APIs is that they provide a single unified endpoint for your backend to meet both client and general API use cases. A single GraphQL API can handle all the client’s requests and forward them to the correct backend service.

As companies and their products scale, REST endpoints can become large and incredibly hard to manage. One of the main problems in REST is the N+1 problem, where the client calls the server N+1 times to get N number of resources, mainly because a single REST resource does not provide enough information for the client to operate with.

Brennan Saeta, an infrastructure engineer at Coursera, cited centralizing REST APIs for simple consumption by the client as one of the reasons why GraphQL API appealed to them.

GraphQL API hides the complexity of the underlying backend system by aggregating the required data from different sources and providing a simple interface that clients can communicate with through a single resource.

Improved Application Performance With GraphQL

GraphQL API improves application performance by reducing JSON payload size and network overhead from multiple API calls. By allowing the client to specify its data requirements, GraphQL APIs eliminate the need for unnecessary generic data being passed from the back end and minimize the number of roundtrips required to retrieve back-end data.

As companies scale and iterate their products, the data required by different clients and pages changes. In REST API design, when new requirements arise, developers must decide whether to create a new endpoint and have clients make a new request for that data or add more data to an existing endpoint. The first option leads to more server roundtrips, and the second option increases payload size, which can hinder app performance.

With more applications being accessed over flaky mobile networks and app speed being an important metric for retaining users, minimizing server roundtrips and data transferred over the wire is paramount. Companies like Netflix and Pulley have reported faster page load times and overall app performance after switching to GraphQL APIs.

With GraphQL APIs, clients receive only the data they specify from the backend server in a single trip, saving network bandwidth and resources.

Improved System Reliability

GraphQL API improves system reliability by ensuring that client queries are valid and in sync with the GraphQL schema specification before query execution. GraphQL uses a type system that describes what type of data can be queried from the backend server and in what form it exists. A strongly-typed schema offers enhanced security over REST APIs by preventing breaches like SQL injection and unintentional data leaks, resulting in a more secure and reliable application.

Type-safety ensures that any breaking changes by the backend server would be caught by clients consuming the data, resulting in less downtime. With GraphQL APIs, you can modify and deprecate API fields while still maintaining backward compatibility. It is easier to know which fields in the API are being used by what clients and which ones are not. With GraphQL, API developers can confidently make changes to the existing APIs without breaking the existing functionality.

Swiggy, India’s largest food delivery platform, discussed how adopting GraphQL API for their back end enabled them to make changes to their existing APIs without breaking the consumer application.

GraphQL ensures API consistency, reliability and security, resulting in better system performance.

Better Developer Experience

Adopting GraphQL APIs improves the developer experience for both frontend and backend developers. Backend developers want to build APIs that are intuitive and easy to explore and navigate. GraphQL helps with that by reducing the time spent documenting APIs.

Through a concept known as introspection, GraphQL APIs allow clients to query the schema and discover the resources available on it. With excellent tools and libraries like the GraphiQL IDE, the interactivity for GraphQL API endpoints is much more intuitive for the developer.

API consumers want APIs that are flexible, easy to integrate and support a variety of client use cases (web, iOS and Android). Because of REST’s inflexibility, it is challenging to create a single endpoint that can meet all of the client’s data requirements. Often the same client has to call multiple APIs to get the data it needs from the backend. Additionally, with REST APIs, frontend developers have to rely on the backend for API specifications before building product features, leading to slower development time.

Peter Downs, director of engineering at fintech startup Pipe, said choosing GraphQL APIs early on cut their development time by 90%. With GraphQL APIs, frontend and UI developers can quickly and easily iterate on features by simply specifying the data requirements in the GraphQL API, thereby reducing the dependence on backend developers to make changes.

Getting Started With GraphQL APIs

The best way to learn GraphQL is by getting your hands dirty and building applications with it. Depending on your language of choice, there are GraphQL libraries in many different languages to help you get started.

As with any new technology, adopting GraphQL APIs for your back end and building high-performant GraphQL backends requires experience, which is not peculiar to GraphQL alone.

If your application relies heavily on interconnected data, you aim to develop an API to be used across several clients or are looking for a high-performant API solution for your backend that minimizes bandwidth usage, then GraphQL API is a perfect data layer for your backend.

August 31, 2022
VMware Embraces Graph Technology to Manage Multiple Clouds

At the VMware Explore 2022 conference today, VMware launched a portfolio of multi-cloud management tools, dubbed VMware Aria, based on a graph-based data store that captures the resources spanning multiple clouds and their relationship to one another.

Accessed via a VMware Aria Hub platform previously known as Project Ensemble, VMware Aria Graph provides a common definition of applications, resources, roles and accounts in near-real-time across a multi-cloud environment that can consist of millions of nodes.

VMware CEO Raghu Raghuram told conference attendees the Aria Graph is at the core of an effort to enable IT organizations to move beyond “cloud chaos” to embrace a next-generation “cloud smart” approach to managing distributed computing environments that span multiple platforms.

Based on an event-driven platform, the VMware Aria Graph aggregates data pulled from public application programming interfaces (APIs) into a data store residing on that cloud. The data store is based on a federated model so there is no need to move data into a central repository. Instead, VMware is making use of GraphQL to launch queries across a federated data model. In addition, IT teams can discover dependencies and analyze historical configuration data to discover the root cause of any issue. All operational data is now aggregated in a way that creates a single source of truth.

VMware has also provided a set of API services that can be used to integrate the Aria Graph data store with third-party platforms.
In general, the company is committed to accelerating “the great replatforming” of IT environments spurred by digital business transformation initiatives, said Raghuram. The challenges IT organizations are encountering are roadblocks that involve everything from a lack of skills, the weight of existing enterprise applications and fragmented operations and cybersecurity models, he noted.

The VMware Aria graph data store will enable the company to automate a wide range of management tasks, Raghuram said. That includes using the right cloud for the right application and governing and accessing them at the lowest cost possible, added Raghuram. The ultimate goal is to enable a unified developer experience that provides a frictionless multi-cloud experience across a consistent set of enterprise infrastructure, he said.

VMware offerings that leverage the VMware Aria Graph include VMware Aria Guardrails for enforcing IT policies, a VMware Aria Migration tool for automating assessment, planning and execution using the VMware HCX platform and a VMware Aria Business Insights tool that surfaces business insights using machine learning algorithms. The rest of the VMware Aria portfolio is anchored around extensions to existing platforms in the form of VMware Aria Cost powered by CloudHealth, VMware Aria Operations and VMware Aria Automation.

VMware also announced today that its existing VMware Cross-Cloud Service offering for deploying its stack of software across multiple clouds has been extended to add support for the Microsoft Azure cloud.

Overall, VMware claims there are now five million developers in its ecosystem that collectively launch 350,000 projects every week. That equates to roughly 35 new applications a minute, according to Raghuram. All told, VMware claims there are 85 million workloads running globally on its platform.

The bulk of those workloads today still run in on-premises IT environments. In fact, Raghuram noted that cloud platforms still only account for $413 billion in IT spending each year, which is only 10% of the total IT spending that reaches $4.4 trillion each year.

VMware, which is expecting to complete its acquisition by Broadcom in the next few months, is betting that as more of those workloads move to the cloud, the need to centrally manage heterogenous IT environments will play to its strengths.

August 30, 2022
The Quest To Unify With GraphQL, The Modern Data API

There is an ongoing trend in enterprise software: Using GraphQL as an aggregation layer to unify access to underlying data sources and REST APIs. Some call this the supergraph, and others refer to it as a meta layer. The idea is that by providing a more consumable layer to a wide range of internal sources, frontend developers are better equipped to access whatever data they need when constructing applications. But the quest to unify all data sources into a single schema doesn’t come without its share of trials.

GraphQL adoption is steadily increasing, with significant large enterprises making up some of the early adopters. For example, Netflix engineers recently shared how one approach gaining traction is “GraphQL microservices (GQLMS) as a backend platform facilitating rapid application development.” As the use of GraphQL increases across a large enterprise, though, scalability and security hurdles present themselves. These include retaining proper authorization throughout multiple layers and mitigating the risks of an inherently open schema.

I recently met with Hasura CEO Tanmai Gopal to discuss why GraphQL should be used as a middleware element to access and expose underlying datasets and APIs. According to Gopal, GraphQL is becoming the data API for modern applications—this could be a massive positive shift. However, the potential downside is around the time involved in integration. Thus, the key will be automating the integration of data sources so that developers and DevOps teams can focus on the apps and services they’re building instead of maintaining the data model itself.

The Underlying Issue: Data Access

“Data access is a bottleneck,” said Gopal. “It needs to be self-service.”

On one side, there are data producers, such as databases, internal services and external SaaS services. On the other side, there are the clients that consume this data, such as mobile apps, web apps, microservices and APIs externalized for third-party developers.

The problem, according to Gopal, is that the link between both sides is increasingly challenging to implement. It takes time to integrate with HTTP-based APIs and parse JSON payloads. The exchange protocols are dissimilar and you must solve for performance issues, caching and concurrency in data access. What’s more, the authorization context must be maintained for all data sources. These issues are exacerbated since not all developers are accustomed to the nuances of maintaining integrations.

Frontend developers want to communicate with a centralized data store, but also need to mix and match various sources. At this point, Gopal explained, a data access layer is necessary to handle the communication between both sides. Such a layer requires some integration automation to truly get APIs to developers at the edge. And it also requires a simple, unified schema—this is where GraphQL comes in.

Solution: A GraphQL-Based Data API

“GraphQL is an absolutely delightful API to consume,” said Rajoshi Ghosh, co-founder of Hasura. “Using GraphQL as a data API can remove a lot of requirements of legacy knowledge of integration systems and how to securely fetch data.”

The concept involves using GraphQL as an intermediary data API—this would consume all sources, whether they are RESTful APIs, GraphQL services, an Amazon Aurora database or a PostgresSQL-style database—and unify them in a more accessible, pleasing construct. To create a unified API over these disparate sources, a middleware solution must map API resources to logical models and methods and add authorization rules to logical models, explained Gopal.

Although GraphQL enables developer agility, it’s the part in the middle that’s difficult to assemble. Building these connectors from scratch requires a lot of relearning and tedium to maintain, Ghosh said. And to truly cater to all data sources, organizations will likely need to craft custom plugins for legacy sources, he added.

Solving Unified Graph Problems

Data-driven initiatives are a common technology goal, but the breadth of data sources is rising. GraphQL can play an important role in uniting these sources and providing flexibility for frontend developers to call precisely what they need. A unified graph is thus a boon for developer experience but will be challenging to set up from scratch.

Arguably, authorization is the biggest challenge when approaching GraphQL as an aggregation layer for multiple APIs. Any system that unifies multiple backend APIs must ensure that only the person with the correct permissions can access underlying data. A unified GraphQL layer must retain granular permissions that are endpoint-centric and unique to the specific caller.

“Most enterprises don’t have a good authorization story,” Gopal said. Implementing authorization for data APIs is hard, Gopal said, as it’s unlike REST where the user ID can literally be specified within the URL request. These kinds of fine-grained attribute level entitlements must be recreated as a policy engine and applied to the graph API as well. For example, Hasura implements authorization by using a token that scopes the entire experience to the particular user.

The Future of Unified API Strategies

Looking to the future of this area, Ghosh noted that frontend stacks are becoming more robust and code in the backend is essentially becoming business logic deployed as serverless functions. And in this new reality of increasing abstractions, the role of modeling experts will likely become more important.

Furthermore, GraphQL must go beyond read-only capabilities to embrace another trend—real-time. Although most GraphQL APIs retrieve persistent data, GraphQL-based data brokers must also evolve to implement streaming, said Gopal, as real-time data and event-based subscriptions are becoming more common.

Today, you probably don’t need to unify all your sources into a unified data model all at once. This activity will likely be relegated to particular business domains or products to help them accelerate and demonstrate a proof-of-concept. But in the coming years, there will be mounting pressure to adopt a unified approach, Gopal said. “In a few years, if you don’t have a unified API strategy, you’ll have a massive problem.”

July 11, 2022