devopsy.kinsta.cloud

Tag: REST APIs

Can Rust Improve Real Django API Performance? Testing Django-Bolt Beyond Synthetic Benchmarks

For teams already using Django, Django-Bolt offers a way to improve API performance without switching to another framework. It keeps Django in place but uses Rust to handle incoming web requests. In its current published benchmarks, Django-Bolt reports 311,000 requests per second for a simple JSON endpoint. The project is careful about that number, though. It notes that benchmark results depend on the hardware and are better used for comparison than as a prediction of what an application will do in production.

The question I find more useful is what happens after the request stops being simple. A real Django API may need to check a user’s identity, retrieve records from a database, run application logic and prepare the response. Each of those steps adds time that the simple benchmark never had to account for.

There is little doubt from the headline benchmark that Django-Bolt can handle a simple request quickly. What I would want to know before considering it for an existing application is how much of that advantage remains once the API starts doing the work it was built to do.

Understanding What Django-Bolt Actually Changes

Most teams running a mature Django application are not looking for an excuse to replace it. The models work, the authentication is already wired in and years of application logic may depend on Django. Things get more difficult when the API needs to handle more traffic, and serving those requests begins to get in the way.

Django-Bolt changes this by moving more of the HTTP work into Rust. Actix Web powers the HTTP server, while PyO3 provides the connection back to Python when the request needs Django’s ORM, authentication or application code.

What I find more useful here than the choice of Rust itself is how contained that change can be.

A team can test a different serving layer without first turning the exercise into a rewrite of the Django application. For a codebase with years of models, permissions, middleware and integrations behind it, that is a much smaller change than moving the API to another framework.

Once Actix Web hands the request to Python, Django still has the endpoint’s real work to do. The response may depend on a database query, application code or another service that answers first. Whatever happens there still adds to the time the user waits.

Why Synthetic Benchmarks Often Tell an Incomplete Story

A static JSON endpoint doesn’t ask much of the application. The request comes in, a simple response goes back out, and there is still very little in between. That makes it easier to see the speed of Django-Bolt’s Rust-powered server.

There is nothing wrong with testing it this way. If you want to know how much overhead the framework adds, keeping the endpoint simple makes sense. I become more cautious when that requests-per-second number is used to suggest what an existing API might handle. The endpoints people actually depend on are usually doing more. They may authenticate a user, query the database, check permissions and prepare a response before anything goes back to the client.

So, I wouldn’t throw out the lightweight benchmark. I would just be careful about what I use it to prove. That way, it can tell us how quickly Django-Bolt handles a request when there is very little application work in the way. It cannot tell us how much faster an endpoint will become when most of its time is already being spent inside Django or waiting for data.

For a team testing Django-Bolt, I would take one of the endpoints they actually care about and benchmark that next. Keep the database calls, authentication and application work that normally happen there. A lower number from that test may be far more useful than an impressive result from an empty endpoint, because it tells you whether Django-Bolt is speeding up a part of the application that was actually holding it back.

Designing a Fair Performance Test

The test should show what happens to Django-Bolt’s lead as the endpoint takes on the work a real API has to do. Putting database access, authentication, application logic and serialization into the first test makes that harder to see.

Begin with a small endpoint that keeps most of that work out of the measurement:

@api.get(“/json-1k”)

async def json_1k():

return JSON_1K

From there, add database access while leaving the hardware, concurrency and the rest of the test setup unchanged.

@api.get(“/users”, response_model=list[UserSchema])

async def users():

return [user async for user in User.objects.all()[:10]]

That’s the gap I’d focus on. If Django-Bolt has a large lead on the first endpoint and a smaller one after the ORM is involved, the database work has already changed the result. Authentication, larger responses and additional application work can then be added separately. Doing this separately makes it much easier to see where Django-Bolt’s advantage changes and what caused it.

Requests per second should not be the only number on the screen either. I would keep p50, p95 and p99 latency beside it and watch CPU and database activity as the load increases. A server can finish more requests overall while some requests are quietly taking much longer. If that only appears at p99, an RPS chart will miss it.

Faster request handling can also change what happens at the database. If Django-Bolt sends more requests through the application in the same amount of time, more queries can arrive at the database within that window as well. The API may report higher throughput while query waits begin to climb. In that case, Django-Bolt hasn’t slowed the database; it has exposed a limit that the slower request path was helping to hide.

By the end of the test, I want to know where Django-Bolt actually saved time, how much of that saving remained once the database and application code got involved and what started slowing down next. That tells a team much more than the final RPS number. It shows where Django-Bolt genuinely helps their application and where they may need to look next.

Benchmark Results: Where Django-Bolt Wins and Where it Doesn’t

Django-Bolt’s biggest gains are easier to see on endpoints that don’t spend much time waiting on anything else. Add database work and that advantage has something else to compete with.

An async ORM endpoint fetching 10 rows from SQLite reaches roughly 21,000–27,000 requests per second. I wouldn’t carry that number over to an application running PostgreSQL or MySQL. What caught my attention was what happened once fetching data became part of the request. Django-Bolt could still handle the request quickly, but it couldn’t do much about the time spent waiting for the database. If an endpoint is already slow because most of its time is spent on a query, speeding up everything before that query won’t change much. Django-Bolt can get the request there sooner, but it can’t make that query return sooner. If the database wait grows under load, the time saved before the query matters even less.

A faster server may also put more pressure on the database. If Django-Bolt handles more requests in the same amount of time, the database may have to handle more queries too. That can show up as longer query wait times as load increases. The server can look much faster while the endpoint itself improves by far less.

Before reading too much into the benchmark, look at the endpoints you’re trying to fix. If they’re slow before they reach the database, Django-Bolt could help. If most of the delay comes from the queries themselves, getting to those queries faster won’t solve much. You’d be speeding up the wrong part of the request.

Does Faster Serialization Improve Real API Performance?

Django-Bolt uses msgspec for serialization, and the performance numbers help explain why. Its benchmarks report roughly 10–85x faster encoding and decoding for supported types than several alternative Python libraries. These results are impressive, but they come from testing serialization on its own. An API has plenty of other work to do before a response reaches the client.

A simple schema looks like this:

import msgspec

class User(msgspec.Struct):

id: int

username: str

email: str

Where msgspec starts to earn its place is on endpoints that require a lot of data preparation. Returning a small object doesn’t leave much serialization work to speed up. Return hundreds or thousands of objects, especially on a busy endpoint, and the time spent turning that data into a response can become much harder to ignore.

Serialization benchmarks can make the gain look much larger than what eventually shows up in the API. A faster serializer helps, but only with the time the endpoint was spending on serialization to begin with. If that was already a small part of the request, there simply isn’t much time to win back. Larger responses give msgspec more work to speed up, and that is where the difference is more likely to show.

Performance is Only One Deployment Decision

A strong benchmark result doesn’t tell you whether Django-Bolt is worth running in production. Someone has to deploy it, debug it and keep it working after the performance test is over.

Django-Bolt adds Rust to an application the team may have spent years running as Python. The Django application may look much the same, but troubleshooting won’t always stop there. If a request fails before it reaches the Python code, the team may have to look beyond the part of the application they know best. Engineers who already work with Rust won’t find that unusual. For a Python-only team, it is extra ground to cover when production is already having a bad day.

Django-Bolt is still listed as Alpha on PyPI. That wouldn’t stop me from testing it, but it is something I’d keep in mind before using it in production. Django REST Framework and FastAPI have been around much longer, so more help is available when something goes wrong. With Django-Bolt, the team may have to figure out more things on its own. That extra work only makes sense if Django-Bolt makes the application fast enough to be worth it.

The cost of running the stack still has to make sense given the performance you get. If the serving layer is already holding back the application, the improvement may well justify the extra work. But if most of the slowdown is happening elsewhere and Django-Bolt barely changes the result, taking on more to run and maintain starts to make a lot less sense.

Final Thoughts

Django-Bolt shows that a Django application can achieve faster serving without abandoning the framework it was built on. The benchmark numbers are impressive, and some of that speed can carry into real APIs.

How much carries over depends on where the application is already spending its time. When request handling is a source of slowdown, Django-Bolt can make a noticeable difference. For teams considering Django-Bolt, it makes sense to test against the API they already run. The result that matters isn’t the biggest number on the benchmark page. It’s what happens to the endpoints they actually need to make faster.

September 16, 2026
GitHub API Abuse, ‘Ghost’ Accounts Part of Malicious Efforts to Map Organizations

A cluster of coordinated and overlapping campaigns that have been running for several months is abusing GitHub’s API and leveraging dozens of “ghost” accounts that have been dormant for years to map organizations and their developers.

Many of the operations are using the API to scrape public information; some have gone further, including cloning private repositories, compromising users’ tokens, and, in one case, exfiltrating data from a private repository, according to researchers with Datadog.

The campaigns are not the result of a single bad actor, but what Julie Agnes Sparks, senior security engineer with Datadog, described as a “blend of custom automated scanner tools, opportunistic abuse of leaked credentials, and coordinated networks of burner (ghost) accounts.”

“Individually, most of these requests are unremarkable,” Sparks wrote. “They hit public endpoints, authenticate cleanly or not at all, and return successful responses. The concern lies in the aggregate: a group of accounts moving in sync across companies’ GitHub organizations with versioned custom tooling iterating over weeks, and in the worst case, actors that stopped enumerating and started cloning.”

Threat to Public Repositories

In the larger context, the coordinated campaigns are another example of how threat groups are increasingly targeting developer environments by compromising the code repositories – like GitHub, npm, and the Python Package Index (PyPI) – they rely on. Fortran noted that GitHub has become the “standard for version control and collaborative software development,” given that it hosts more than 420 million repositories and serves more than 150 million developers around the globe.

The threat is only growing. According to Jacob Malimban, cyber analyst with Cofense, the number of malicious campaigns against Git repositories has grown every year since 2021 – with almost 50% of the abuse during that time period happening in 2025 – primarily for credential phishing or to deliver malware.

Cofense found that 95% of the campaigns targeted GitHub, with 5% abusing GitLab. In addition, 58% delivered credential phishing, with the other 42% bringing malware.

No Authentication Needed

According to Datadog’s Sparks, much of what’s available through GitHub’s API can be reached without authentication. That includes an organization’s public repositories, its users’ followers and following lists, starred repositories, and organizational memberships. Likewise, running GraphQL queries against public objects can also bring in data. Given that all of these pathways are public, there’s no alert regarding authentication.

“An operator can build a detailed map of an organization, such as its public repositories, its members, who those members follow, and which projects they touch, entirely from public data,” she wrote. “This traffic blends into normal API usage.”

Another challenge is that with external resources, GitHub doesn’t collect geolocation data for events, which limits attribution based on where the signal is coming from and the VPN or proxy used. That said, the logs do record the GitHub actor that makes the request and the kind of access tokens they use.

The Use of Ghost Accounts

Another way the campaigns are keeping under the radar is through the use of ghost accounts. Datadog found more than 50 such accounts being used by the bad actors that have been left dormant for anywhere from two to five years before being activated to send API traffic to multiple organizations. Sparks noted that an account that’s existed for multiple years often is considered more legitimate than one registered the same week it begins scraping data.

The threat actors tend to use the ghost accounts for one to three weeks before their use ends. While in use, the accounts are given a mixture of names, from GitHub-Company-Scraper and GitHub-Scraper-Tool/1.0 to more benign-sounding names such as GitHubAnalytics/1.5.

Most of them target GraphQL, an open-source query language for APIs, while others look to REST, which Sparks said is what’s expected when talking about mapping organizations. It won’t give abusers access, but it will allow for reconnaissance.

Exposed Personal Tokens

Some campaigns used personal account tokens (PATs) exposed by users who posted them accidentally or had their systems compromised. One campaign between December and January used three stolen tokens from a progression of the same user agents and ran its infrastructure on a hosting provider, 3xK Tech, which has been the subject of several abuse reports.

“Dozens of distinct legitimate GitHub user accounts made API requests to a single organization within a window of only a few minutes,” Sparks wrote. “Their requests targeted private repository commit paths, and in this campaign, the attempts failed. The functional focus of this campaign was narrow and consistent: listing organization repositories, fetching commits, and probing private repository paths.”

There were a handful of cases in which campaigns were able to access data. In one, a user agent with the handle “repo-dumper” exfiltrated data from a private repository using a mix of Git cloning and API requests.

Keep an Eye on Indicators

Sparks wrote that among the indications of unauthorized activity in an organization’s environment are user agents, event activity, and actor names. Datadog researchers are detecting a rise in legitimate vibe-coded or custom tools that have names similar to user agents they’ve identified.

“It’s important to know what normal looks like in your environment,” Sparks wrote. “We suggest enabling GitHub audit log streaming, baselining your user agents, proactively threat hunting, and developing detections unique to your GitHub organization.”

July 14, 2026
GraphQL API Visibility Ensures Enterprises Can Escape Lock-In

While GraphQL is still early in its enterprise adoption curve, the runtime query language (and replacement for REST APIs) has already built an impressively robust ecosystem for jumpstarting major enterprise-grade deployments. Among the appeals of GraphQL are its open source implementations and breadth of available server types, which combine to offer enterprises flexibility and the benefits of best-fit solutions.

However, operating GraphQL in production, maintaining GraphQL APIs at enterprise scale and achieving the requisite GraphQL visibility and security require complementary tools and services. This is where enterprises can fall prey to vendor lock-in and lose the flexibility to change and control their own deployments if they aren’t careful.

Enterprises need vendor partners to manage their GraphQL deployments effectively, and vendors are glad to offer comprehensive SaaS solutions. But enterprises must understand that a vendor can seek to capture their long-term business by coercion—straitjacketing customers by hosting their entire GraphQL infrastructure and GraphQL gateway and making it, well, not exactly easy to let go. They can unleash particularly nefarious practices, using proprietary features to force customers to migrate to certain technologies or purchase expensive upgrades to keep their crucial GraphQL deployments afloat. Enterprises must be wary of allowing this vendor lock-in to happen for their own good.

Knowledge is essential to maintaining the balance of power in vendor relationships. Enterprises must understand their GraphQL graph and key measures to correctly assess current vendors and maintain agility and control over deployments by not entrusting their entire fate to any one partner.

These are the specific areas where enterprises should seek out intelligence and reliable metrics in order to choose their own future with GraphQL:

Understand Your Overall Graph (and Subgraph) Utilization

Establishing an accurate overview of your graph utilization—and harnessing actionable insights—are crucial, foundational steps that lay the groundwork for deeper analysis and better decision-making. You need to know what graph and subgraph objects and operations your most important API users heavily engage with and which objects and operations are underused or not used at all. You need visibility into who is using GraphQL APIs and how. Getting to actionable intelligence should also tell you where errors are most likely to occur and what’s causing them, as well as where major performance bottlenecks pop up during heavy load events.

With this overview available, the next steps call for building a depth of knowledge in each of these five areas:

1) Understand areas of heavy graph and subgraph usage

Knowing exactly where heavy usage occurs in your graph puts you in a position to upgrade or migrate your GraphQL API server or gateway on your terms while mitigating outage and error risks. Specifically, you want to know which operations in your graph are executed most and how often, which graph objects and fields are consumed most often, and which subgraphs support those most heavily burdened areas in your supergraph. This knowledge and some careful planning help to put successful GraphQL server or gateway changes within your power and also reduce risk when introducing changes to areas of the graph under heavy consumption.

2) Understand where your graph is underused

GraphQL migration and modernization efforts are simpler—and carry less risk—when you first remove any unused functionality and reduce your scope as much as possible. To do so, you need visibility into your graph’s least executed operations, objects and fields, and subgraphs, as well as any operations with zero recent usage. Then, flag low-use graph areas you can deprecate, replace or just remove to simplify your deployment before making changes.

3) Understand your GraphQL API users and usage

You want a seamless experience for your GraphQL API users throughout any changes you make, especially for the users and graph-usage patterns most crucial to your business. That means knowing the frequent users of the areas of your graph under the most heavy usage. You also want to recognize and bolster any GraphQL operations that your most important users frequently call, in addition to the objects and fields those users consume.

4) Understand graph errors and potential error hotspots

The right actionable intelligence will prepare enterprise teams to anticipate and address graph errors. This requires visibility into where, when, why, and how often graph errors occur and error hotspots (for example, high P95 latencies indicative of potential timeouts). Insights into which users feel the brunt of graph errors are also valuable in shaping mitigation strategies.

5) Understand graph performance bottlenecks

Bottlenecks caused by your GraphQL server or gateway itself may call for a shift in your graph’s underpinnings. Bottlenecks can also arise from costly queries of substantial depth and height, especially when these queries see intensive use.

To foresee and address bottlenecks, actionable insights include the average and P95 latencies of your graph’s most-called operations and the heights and depths of your graph queries with the worst performance metrics. You also want to know the number of times that bottlenecked operations get called each day, the subgraphs at the root of bottlenecks, the latency added by supergraph query planning, and which users are impacted the most by bottlenecks.

Graph Knowledge = The Power to Avoid Vendor Lock-In

Implementing the GraphQL API visibility and actionable intelligence strategies covered here help ensure that an enterprise has the means to modernize or migrate as necessary to preserve its strategic independence. Those unfortunate organizations already in the grip of vendor lock-in may need to bide their time but should still use these same techniques to improve and decouple their fundamental GraphQL services from their vendor-controlled GraphQL technology. There’s no acceptable reason why organizations relying on free and open source GraphQL servers and gateways should find themselves stuck in proprietary software arrangements. Thankfully, the right knowledge can deliver enterprises a more flexible future as they modernize API development with GraphQL.

October 4, 2023
Data APIs: Realizing the Future of Data Warehousing
Data is the currency of business in today’s digital economy, with organizations collecting mountains of data from their customers, products and services. Enterprises are increasingly turning to data warehouses to store this valuable enterprise data and to make it useful and actionable. Data APIs–both GraphQL and REST–are emerging as a tool to power frictionless and high-quality integrations between applications/services and data in enterprise data warehouses. But what exactly is driving this shift toward using APIs on top of data warehouses? In this article, I will talk about the drivers behind the rise of data APIs on data warehouses, challenges with current approaches to building, operating and scaling data APIs and how organizations can address those challenges.

The Rise of Data APIs

Data APIs enable organizations to create powerful integrations between applications without having to go through lengthy development cycles or write complex code. As a result, businesses can deliver improved user experiences faster than ever before by quickly connecting disparate applications and services together using intuitive REST or GraphQL endpoints. Because these endpoints are standardized across multiple systems (e.g., REST or GraphQL), developers don’t have to learn new languages or coding techniques every time they want to connect two different applications together. This makes it much easier for developers to work with multiple systems simultaneously while still ensuring that all applications remain connected via one interface–the API endpoint itself.

Challenges With Current Approaches

Despite all these advantages provided by Data APIs, there still remain a few challenges that organizations need to consider when building out their own solutions. For example, many existing approaches require manual setup processes, which can be extremely time-consuming and tedious for developers working with multiple systems at once. In addition, many existing solutions only allow for limited query functionality, which means that more complex queries may not be possible without additional coding or manual setup processes being performed. Finally, some existing solutions require an extensive amount of organizational resources in order to build out a full-fledged solution—time that could be better spent on more important tasks like product development or customer service initiatives.

How Organizations Can Address These Challenges

Fortunately, there are now tools available that make it easy for organizations to quickly build out powerful data API solutions with minimal effort required from their developers or IT staff members. These tools provide pre-built templates that can be used as a starting point for any integration project while also allowing users to customize their own solution based on specific needs and requirements without having to write any code themselves. Additionally, these tools allow users access to advanced query functions such as joins across multiple tables so they can get the most value out of their databases without compromising either speed or security either. Finally, these tools also include powerful monitoring capabilities so users can ensure that their data APIs remain running smoothly at all times, no matter how much traffic they receive.

Benefits of Using an API for Integrating Cloud Data Warehouses

When it comes to integrating cloud data warehouses into your application or service, there are several advantages that come with using an API as opposed to traditional methods such as manual coding or ETL tools:
- Increased Flexibility: By leveraging an API, you are able to access data from multiple sources quickly and easily without having to manually code every integration yourself. This also allows your application or service more freedom when it comes to accessing additional data sets in the future; all you need is an existing API connection in place.
- Improved Security: Since APIs are designed specifically for secure communication between different systems, they offer enhanced levels of protection against malicious attacks such as DDoS attacks or unauthorized access attempts. You can also add additional layers of security by implementing authentication protocols like OAuth or JWT tokens on top of your existing API connection.
- Enhanced Performance: APIs can be designed with specific performance optimizations in mind; this means that you can create custom solutions tailored towards the exact needs of your application or service which will ultimately result in improved end-user experiences and higher engagement rates from customers who interact with your product or service regularly.
Data warehouses have become an essential part of modern digital businesses due to the sheer amount of valuable enterprise information they store. However, traditional approaches can often lack the flexibility or scalability needed in order for businesses to stay competitive in today’s ever-changing market environment. This is why smart organizations are using data APIs on top of them for quick integration among disparate applications/services along with advanced query capabilities.

By leveraging tools designed specifically for this purpose, companies can easily overcome current challenges associated with building out their own solutions while still getting maximum bang for their buck when it comes down to successful implementation and operation over the long term.
March 23, 2023
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
Does GraphQL Introduce New Security Risks?

The GraphQL query language is an excellent tool for increasing the ease of data sharing. The premise is that you request the fields you need in a single bundled request, avoiding multiple network calls. Due to its usability, GraphQL is a growing area of development. Yet, as with any new technology, it comes with caveats.

REST APIs function as a request-and-response paradigm in which the receiver accesses one resource at a time. On the other hand, GraphQL exposes many fields at once, requiring additional rate-limiting and time-outs to avoid nefarious queries. Additionally, the ability to traverse the entire schema could be abused by attackers to expose intricate data linkages. There are also some usability features with GraphQL that could be abused if misconfigured.

GraphQL is a friendly alternative to REST. But how do we handle the security implications of GraphQL? I recently chatted with Mike Benjamin, vice president of security research, Fastly, to dive deeper into the security repercussions of adopting GraphQL. Below, we’ll consider the unique insecurities associated with GraphQL and suggest specific steps to limit the impact of these risks.

Four GraphQL Security Vulnerabilities

1. Introspection

GraphQL provides built-in documentation that tells developers what the fields are, providing a schema of everything you can query. You’ve essentially given the entire dataset schema to a developer, meaning they can perform introspection to capture attack surface information. Hackers will most commonly look for injection or mutation capabilities that they can exploit, explained Benjamin. Or, they might seek to leverage the interlinkages between data to map a way through to classified information.

To mitigate this problem, Benjamin cautioned against over-exposing all documentation publicly. Instead, he suggested using a restrictive security model for external viewers. “Provide appropriate user documentation in a different method,” he says. This may end up looking more like the standard REST API view of documentation.

2. Field Suggestions

Another usability benefit in GraphQL could also be a potential security concern—field suggestions. Field suggestions occur when you don’t enter the correct field name or enter a partial input and the system returns a hint. You might type in 0 or user, and the system makes a suggestion to fill out the rest of the field.

This user interaction improves the developer experience, but, unfortunately, it could be abused by a hacker, said Benjamin. Thus, he recommended disabling hints after initial development. Or, if you decide to keep it in, he recommended placing a limit on its use. For example, if you try this more than five times in a second, the system could flag it as a bot.

Right now, this attack vector is pretty limited, but Benjamin anticipated that, over time, hackers could automate this introspection with mass scanners to divulge more information.

3. Denial-of-Service-Oriented Attacks

Without the proper guardrails, all web APIs are prone to denial-of-service (DoS) attacks. Such an attack may pummel a service with a million queries per second to shut it off completely. In the case of GraphQL, these queries can dive very deep in a nested data relationship. A social network, for example, might expose friends of users, friends of users’ friends and so on.

Or, hackers might utilize GraphQL’s bulk query ability to perform reconnaissance, brute-forcing the enumeration of data to query hundreds of user IDs to see which are valid. If you’re allowing unlimited data retrieval bundled within a single request, you could be inviting hundreds of bundled queries that could expose large swaths of the underlying database in one fell swoop.

To counter these actions, Benjamin recommended limiting the testing depth. This could involve placing limits on how long a query can run, which would cause a time-out for requests that require suspiciously high degrees of processing. Another option is to limit how deep the bundling can get, said Benjamin. For example, perhaps the system restricts going three levels deep into a graph database, as that could expose millions of interconnected endpoints.

4. Lack of Object-Level Authorization

Another vulnerability that GraphQL endpoints may be prone to is a lack of object-level authorization, which hackers could leverage to get at a datapoint through its edges, said Benjamin. Since the idea is that you can access any data from one all-encompassing endpoint, authorization rules are often too abstracted away from the actual data. Queries may be able to access nested data or query relationships between data, too, which may unintentionally divulge information.

Benjamin recommended placing authorization closer to your objects or data to rectify this issue. Use authorization-level controls that align permissions structure and roles with users. “Everyone needs a common authorization model,” said Benjamin.

Future Evolution: GraphQL Security Matures

As I’ve written before, the greatest strength of GraphQL is also its greatest weakness. Using GraphQL with default settings is a security trade-off in favor of usability. But according to Benjamin, we’re seeing more GraphQL servers disabling some introspection features, which he sees as a very positive move and a sign of maturity of the base configuration.

GraphQL might suffer from similar threats that all APIs are vulnerable to, such as XSS, injection, DDoS attacks and broken authorization. However, Benjamin stressed that the added complexity of GraphQL makes it a unique case. “The most important thing for folks to consider is that GraphQL is more complicated than a REST endpoint—much more complicated,” said Benjamin. “GraphQL is unique in that it has linkages of data which contributes to complexity. It takes a little more time to think about how that’s confirmed, how it’s presented and how it would be attacked.”

In other words, with great power comes great responsibility.

Although exploits in public GraphQL APIs are still rare, we should stay vigilant. Benjamin encouraged developers to continue reading about, understanding and thinking about these attack vectors when designing their interfaces, as these risks will become more prominent as GraphQL usage grows and hackers become more familiar with these specific frailties.

May 10, 2022
Smoothing the Transition From REST to GraphQL
Since its open source release in 2015, GraphQL has taken the development world by storm. GraphQL, the query language originally developed by Facebook, is a big boon for frontend developers, as it enables you to grab the exact data you need with a single request. This solves the problems of over-fetching and under-fetching, which classical REST APIs are prone to. GraphQL also offers a nice developer experience with a consistent schema and documentation. Some are even treating GraphQL as a convenient meta layer to aggregate multiple underlying services and abstract their interfaces with simple commands.

For these reasons and more, many development teams are considering switching from REST to GraphQL. Even enterprises are beginning to use GraphQL in large production environments. But, how can these teams make the switch without breaking existing integrations? How can we ensure that things like developer experience, security, and access control all remain stable?

I recently met with Anant Jhingran, the co-founder of StepZen, to discover tips for transitioning from REST to GraphQL. According to Jhingran, most organizations see the benefit in adopting GraphQL but are hesitant to forgo years of investment into RESTful architectures. But according to Jhingran, it’s rarely a case of “either/or”—more often, he sees projects running both styles simultaneously or layering one on top of the other. Below, we’ll explore some things to keep in mind as you invest in GraphQL.

The Decade of Developers

We’ve reached ubiquity of web APIs among companies big and small. “APIs have turned out to be phenomenal for software supply chains,” said Jhingran, the former CTO of Apigee. They help share data between partners and can enable platform ecosystems to thrive. Jhingran describes how within the last decade, APIs and API management have peaked to near-ubiquity in terms of adoption.

But not all APIs behave the same way. Although representational state transfer (REST) is the most popular style, it’s still quite a general architectural guideline for web APIs—how the data comes out of each service is still highly nuanced. The structure of requests and responses are different from service to service, causing developer experience hangups at scale.

GraphQL, on the other hand, “is a fantastic way of structuring data,” said Jhingran. With a single call, you can return the explicit information that the client requires in an expected format. For an e-commerce application, for example, this might be customer information, order numbers and delivery status. Displaying this all with one call is an awesome experience for frontend developers. And, GraphQL APIs are easy to explore and navigate since the schema is baked in. This improves upon REST APIs, where documentation may not always match the actual production implementation.

“This decade is the decade of developers,” said Jhingran. Satisfying developer experience has become more mission-critical as enterprises work to increase their footprint in the cloud marketplace and GraphQL is part of this movement. “For people who build apps, it’s just better,” said Jhingran.

But just because frontend teams clamor for the ease of use of GraphQL doesn’t mean backend teams can easily restructure their entire framework around it. Doing it right requires many skills, and the journey can be arduous, explained Jhingran.

It’s Rarely REST Vs. GraphQL

REST and GraphQL are often pitted against one another to the point that they seem like polar opposites. But in practice, teams often use GraphQL to build on top of APIs already in place. Jhingran describes the most common pattern as “GraphQL comes in as a layer that connects the dots between various REST APIs.” Either GraphQL is consumed directly or as a REST layer above GraphQL. “It could go either way,” he said.

GraphQL is a fantastic data infrastructure tier as it can mix and match database backends. It could, in essence, become the new plumbing upon which applications are constructed. But while GraphQL may be excellent for internal construction, the name of the game is stability when externalizing services to the outside world. With REST, the big goal is to decrease broken clients and ensure high-grade security for each resource. Therefore, Jhingran foresees certain use cases where using a REST wrapper around GraphQL services to deliver fixed JSON responses would be preferred.

Another point is that GraphQL is not only relegated to appeasing frontend developers—it has some backend potential, too. “GraphQL is an opportunity to reimagine frontend and GraphQL is an opportunity to reimagine backend infrastructure,” said Jhingran. This concept has weight nowadays, as Netflix engineers, for example, use GraphQL as a backend for microservices architecture.

Making the Transition From REST to GraphQL

Not all apps are going to be transformed on day one. Teams may encounter cultural resistance to new technologies. Interface redesigns, especially for those external apps which are exposed to third parties, must also require extra precaution to maintain app compatibility to avoid breaking change.

Thus, it may take time to transition effectively. “Getting it started versus getting it right are not the same thing,” said Jhingran. He said people who get started with GraphQL may struggle for months due to competing best practices and tools. For example, Jhingran identified two main perspectives when approaching GraphQL: Programming and declarative.
- Programming: Teams use GraphQL libraries such as Apollo to program their way out of your GraphQL endpoint. In this approach, you just start writing. It’s quick to get started, said Jhingran, but you end up describing everything you do and encountering many contingencies along the way.
- Declarative: The other option is a more declarative approach—instead of telling the system how, you tell it what to do. For example, this subsystem should do X, this subsystem should do Y and so on. According to Jhingran, adopting tooling with declarative snippets to create GraphQL endpoints is “better in the short and long run.”
GraphQL Security

A March 2022 report from Salt Labs found a shocking 681% increase in API-based cyberattacks over the previous 12 months. There are many concerns surrounding API security right now—these valuable endpoints are prone to broken access control, data overexposure and over-permissive states.

As I’ve covered previously, GraphQL security is a bit nuanced compared to REST. Within the REST paradigm, you can easily assign permissions and rate limit calls per resource. But with GraphQL, it’s not that simple. Since you can batch multiple queries, callers have much more power at their fingertips, and hackers might abuse such power if the proper authorization isn’t in place.

Companies may rightly worry about opening another can of worms with GraphQL. But according to Jhingran, these worries are all solvable. A comprehensive GraphQL endpoint will likely require another layer to uniquely segment authorization to retain a least-privilege model for all resources and backend endpoints.

Future of GraphQL

To date, GraphQL has gained modest prominence. But, Jhingran foresees an incoming inflection point in the next two to three years. “The dominoes are beginning to fall,” he said.

Now that the market is saturated with APIs, characteristics outside of functionality will be what sets a service apart and gives it a competitive edge. This includes things like performance, security and developer experience, the latter of which makes GraphQL an attractive proposition. This, paired with the explosion in GraphQL tools, will undoubtedly help developers perform their jobs better.

Looking to the future, Jhingran predicts increased usability and abstraction in how developers work with GraphQL. He compared it to how disjointed pages on the web became interconnected and searchable with links. We see similar thinking happening in the world of APIs, he explained, in which the disjointed APIs require a better connection. Similar to how Google simplified search, he foresees GraphQL and the tools that work with it helping to decrease cognitive load by abstracting complexity with declarative commands.
May 5, 2022
Hasura Adds Join Capability to GraphQL Engine

Hasura today announced it has extended its GraphQL engine to make it possible to join data generated by multiple sources.

Hasura CEO Tanmai Gopal said GraphQL Joins makes it possible to join data from across different GraphQL services that can then be accessed via a single GraphQL application programming interface (API). The extension of the federation capabilities enabled by the Hasura GraphQL engine eliminates the need for custom code that would otherwise be required to join that data, he added.

The Hasura engine automatically generates a GraphQL schema from a data source that can then be used to accelerate the development of APIs. GraphQL Joins extends that federation capability to now include multiple GraphQL and, eventually, other data sources accessed via, for example, legacy REST APIs, said Gopal. That capability will make it easier for a wider range of developers to build applications that aggregate data across multiple sources, he added.

The core Hasura Engine is based on open source software that the company claims has now been downloaded more than 500 million times. Hasura makes available a cloud service based on that core engine. That approach eliminates the backend complexity that IT teams encounter when adding GraphQL APIs to an application environment that already has a range of APIs that internal IT teams need to support, noted Gopal.

GraphQL was originally created by Facebook, and it’s still not clear to what degree GraphQL APIs will supplant REST APIs. Developers tend to prefer GraphQL APIs because they provide more granular control over what data is accessed. The challenge is the number of backend services that expose GraphQL APIs is still comparatively limited. Most IT teams will not be replacing REST APIs with GraphQL-based APIs overnight, but the percentage of new applications that rely on GraphQL APIs will steadily increase. DevOps teams looking for easier ways to provide developers with access to backend services via a GraphQL API can employ the Hasura Engine to automate that process.

Overall, the number of APIs employed within IT environments is rapidly expanding as more microservices-based applications are deployed. Each microservice generates its own API. Over time, IT teams will find themselves managing a range of types of APIs to support multiple digital business transformation initiatives that an organization may have simultaneously launched. In addition to building APIs, many of those organizations are now consuming data via APIs exposed by another organization. Over time, the level of interdependency between APIs and applications will serve to make application environments much more complex. The good news is that APIs make it easier to upgrade—and even replace—backend services without disrupting application services.

It’s not always clear, though, who within IT organizations will manage those APIs. They are often created by developers that then look to IT operations teams to maintain them. Before too long, it’s not uncommon for IT teams to find themselves managing hundreds, perhaps thousands, of REST and web services APIs—and soon, that may include many built using GraphQL.

April 28, 2022
Netlify Leverages GraphQL to Simplify Access to Backend Services

Netlify this week added a Netlify Graph tool to its portfolio that makes backend services available to developers via a single click. The tool aims to simplify DevOps teams’ access to those services when building their applications.

Netlify Graph is based on the GraphQL query language for application programming interfaces (APIs) and enables developers to integrate services such as GitHub, Salesforce and Stripe within frontend and web application development tools without any direct intervention required from a DevOps team.

Netlify provides an application development framework based on JavaScript, application programming interfaces (APIs) and markup languages, otherwise known as a JAMstack, to isolate frontend and backend components of an application.

Netlify CEO Matt Biilmann said Netlify Graph is based on the GraphQL technology the company gained when it acquired OneGraph. The overall goal is to make it simple for frontend developers to invoke backend services accessed via either GraphQL or REST APIs, he said. Services based on GraphQL can be especially complex for developers to invoke as they navigate the management of tokens and application secrets, Biilmann added.

It’s not clear to what degree GraphQL APIs will supplant REST APIs. However, developers tend to prefer GraphQL APIs because they provide more granular control over what data is accessed. The challenge is the number of backend services that expose GraphQL APIs is still comparatively limited. As GraphQL becomes more widely adopted, the level of effort DevOps teams now need to expend to expose backend services should decline as tools such as Netlify Graph are employed by frontend developers.

As a result, at least theoretically, the rate at which new applications are built and deployed to drive digital business transformation initiatives should increase. Most IT teams will not be replacing REST APIs with GraphQL-based APIs overnight, but the percentage of new applications that rely on GraphQL APIs will steadily increase. DevOps teams looking for easier ways to provide developers with simpler access to backend services now have an incentive to embrace GraphQL.

Ultimately, Biilmann said, the goal is to enable developers to build applications without having to directly engage anyone on the IT team. Each backend service can be managed in isolation from the frontend of any application. It’s not clear how long it might take to achieve that goal, but as responsibility for the end-to-end management of the application experience continues to shift left toward developers, the need to surface backend systems-as-a-service becomes more pronounced. In fact, given the current focus on improving developer productivity, IT organizations might soon face a mandate to embrace GraphQL more broadly. After all, every minute that a developer spends on plumbing is time they’re not spending writing actual business logic.

Naturally, it may take time for enterprise IT to be truly transformed into a set of services that developers can easily consume. But as progress continues to be made, that dream may finally be realized.

February 18, 2022
How Are API Management and Service Mesh Different?
The use of APIs and microservices is increasing—a recent study from F5 estimated that the industry is approaching 200 million total APIs. As organizations expand their use of APIs and microservices, they inevitably require some form of service management architecture. There are primarily two major design options for implementing this: An API management system or a service mesh.

The key distinction between API management and service mesh can be framed using the four cardinal directions. API management is typically adopted for REST services that face external developers—referred to as north-south traffic. On the other hand, service mesh is more commonly used by internal suites of microservices to help control lateral, or east-west, communication. There are more nuances between each, as we’ll cover below, but this is essentially how they’re adopted in practice.

However, this binary is becoming blurred as collections of enterprise digital applications expand and access to cross-company business domains begins to look and feel more like consuming a third-party SaaS. Furthermore, some suggest that with the right controls, service mesh can cater to external users in the same way API management does. What’s more, service mesh and API management are complementary—they can coexist within the same organization and even be deployed in the same projects.

I recently chatted with Mark Cheshire, director of product at Red Hat, about the emergence of both API management and service mesh. According to Cheshire, both approaches accomplished similar goals but evolved very differently. Below, we’ll revisit why these two paradigms emerged and compare and contrast them. In a separate article, we’ll consider when it’s best to integrate them both.

What is API Management?

API management is most often associated with north-south traffic. By exposing your API to the outside world, you enable other developers to connect it to their systems and leverage your data and functionality like building blocks.

API management arose in response to the rise of web APIs. API management is a broad concept encompassing many functions required to expose an API endpoint to the outside world. This can include authentication, authorization, request routing, documentation, rate limiting, monitoring, logging, monetization and life cycle management. A key goal is to make integration easier for the developer consumer. Architecturally, API management follows a gateway pattern. Consumers issue requests to the gateway which then performs routing to the underlying services.

For APIs, the big catalyst was the emergence of Web 2.0, Cheshire explained. Numerous startups began consuming RESTful APIs to connect their web properties and partner ecosystems. Companies also found REST APIs to be a much more straightforward integration approach than SOAP and SOA. They also saw the ease-of-use benefits and adopted API-first designs within their internal infrastructure.

As of 2021, over 70% of APIs are built for internal use. So, do all these services need API management? It depends. “If you communicate externally, you need API management,” explained Cheshire. But, it’s a grey area for services within an enterprise, he says, though inter-domain traffic often could benefit from API management.

A diagram of API management capabilities, from 3scale

Strengths
- Can enable north-south traffic
- Protects the boundary of an application
- Designed to ease external developer consumption
- Potential for monetization, subscription plans
- Typically plug-and-play; easier to support
- Many solutions on the market
- Developer experience and docs
- Analytics and reporting
Weaknesses
- May be heavier than service mesh
- Fewer open source options; vendor lock-in
- Analysis paralysis in comparing solutions
What is Service Mesh?

Service mesh is most often associated with controlling east-west communication between internal services. Service meshes like Linkerd, Istio and Kuma make it easier to reimplement similar logic—such as networking, observability, traffic management, security policies and routing—across many microservices from a single control plane.

Service mesh was born to address slightly different challenges than API management. “The transition from monolithic to microservices is all about east-west traffic,” Cheshire said. Companies found it slower to innovate monolithic applications and thus broke them up into microservices that communicate via APIs. But these microservices all needed similar operational capabilities, which would be cumbersome to repeat over and over for each service.

“For one monolithic app blown into microservices, you may not even need a service mesh,” said Cheshire. “However, when you have hundreds or thousands, that’s when applying service mesh becomes critical.”

Istio service mesh architecture

Architecturally, service mesh is typically divided into a data plane and a control plane. The service mesh deploys a sidecar proxy that sits alongside each individual service. Istio, for example, utilizes the Envoy proxy. Other meshes like Linkerd use their own proxy.

Strengths
- Fits the microservices architecture paradigm well
- Good for traffic routing; improving resiliency
- NIST-recommended architecture for achieving zero-trust
- Many open source options
- Fits large microservices deployments
Weaknesses
- Requires a more hands-on approach
- Potentially more maintenance to support
- Unnecessary for a single service
- Requires filter chain add-ons for north-south abilities
Comparing API Management and Service Mesh

API management is predominantly aligned with externalizing APIs to partners. When you do so, maintaining the contract with a consumer is more important to meet SLAs. Thus, API management commonly delivers life cycle management abilities, such as versioning. API management is necessary even if you are exposing a single API, as this service needs to be adequately documented and secured. That being said, these tenants can also be relevant to developers reusing software within an organization—there’s something to be said for adopting a product mindset when dealing with internal APIs.

On the other hand, service mesh is more aligned with controlling internal networks. Microservices are rarely deployed alone; typically, multiple microservices make up an application. And, many more might exist throughout an organization for unique purposes. Service mesh thus helps maintain consistency throughout large networks of decoupled microservices. Service mesh is also a rapidly growing field, experiencing an explosion of new development and production use. A Cloud Native Computing Foundation (CNCF) report found that service mesh use rose in production by 50% in 2020 alone.

To put the comparison another way, William Morgan, CEO, Buoyant described how API management is more about business logic, whereas service mesh handles intra-cluster operations:

“API gateways typically handle ingress concerns, not intra-cluster concerns, and often deal with a certain amount of business logic, e.g. ‘User X is only allowed to make 30 requests a day’. By contrast, a service mesh like Linkerd is focused on operational concerns (e.g. instrument these calls and report their success rate; secure this communication between these pods) and purposefully avoids the mixing of business and operational logic; and focuses on communication between the services on the cluster.”

Though service mesh and API management achieve slightly different aims, both layers make it easier to reuse web-based services. And, they certainly can be used in conjunction. For example, you could build API-first microservices with service mesh and simultaneously use API management to expose certain domains. In another article, we’ll consider when it’s best to integrate the two technologies.
January 18, 2022