Apollo GraphQL and AWS Double Down on Rust for Enterprise Apps

NEW YORK — Apollo GraphQL and Amazon Web Services are extending their support and use of Rust as adoption increases at a quickening pace.

Although many view Rust as a challenging language to learn, it offers capabilities that surpass other languages in several areas, particularly in performance and security. These capabilities include its ability to work similarly as a compiler with Rust since the exactitude standard the code must meet is seen as being more stringent than other popular languages such as  Go, JavaScript, Python  and others. Also, garbage collection is not much of a worry and can offer security advantages for applications built with Rust.

At the recent GraphQL Summit in New York, one of Apollo GraphQL’s key announcements was about its adoption of Rust for its query. This shift highlights Apollo’s commitment to Rust’s potential, especially in handling high-performance search queries. By integrating Rust, Apollo is looking to enhance efficiency and reliability in search-related functionalities, marking a notable pivot from previous language preferences, especially JavaScript in this case.

During P99 CONF, Carl Lerche, principal engineer at AWS and head of the Rust library open source project Tokio, discussed Rust’s potential in ongoing projects, including the open source Tokio framework and Toast platform, underscoring Rust’s growing use in AWS’s infrastructure.

Matt DeBergalis, CTO and co-founder of Apollo GraphQL, in discussing Rust’s adoption over JavaScript at GraphQL Summit, touched on the strategic decision to transition to Rust, beyond just its benefits for Apollo’s search engine. His remarks highlighted the language’s strengths, suggesting a possible increasing use as part of Apollo’s long-term development strategy.

During his P99 CONF talk, “Rust: A Productive Language for Writing Database Applications” Lerche described his incubation project, Toasty, under the Tokio-rs GitHub repository. As he noted, Rust’s adoption for server-based applications has typically been at the infrastructure level but is extending to use cases such as databases, proxies and routers.

It’s Toasty: an ORM Library for Rust

While Toasty is not ready for production usage and the API and documentation are in development, Lerche described Toasty as an object-relational mapping (ORM) library for the Rust programming language. It supports both SQL databases as well as some NoSQL databases, including DynamoDB and Cassandra. Note that Toasty does not hide the database capabilities. Instead, Lerche said, Toasty exposes features based on the target database.

One of his goals with Toasty is to build a library that prioritizes ease of use over maximizing performance. “That isn’t to say that Toasty doesn’t care about performance. After all, if you are using Rust, you probably want things to be pretty fast,” Lerche said. “But when designing the flow of the user’s happy path, when there’s a design trade-off between ease of use and squeezing out the last bit of runtime performance, I pick ease of use.”

What has “always bothered” Lerche, he said, is the complete ecosystem split between ORMs that support SQL databases and libraries that target other types of databases, “even though there is likely a 90% overlap in functionality.”

“The majority of work these libraries do is to take an application struct and perform create, read, update and delete operations with basic queries, like finding by key or using simple filters,” Lerche said. “This ends up being most of the library’s function, regardless of the database. So, why does every database library have to reinvent the same thing?”

There’s value in users becoming familiar with one library, Lerche said, and being able to apply that familiarity across different contexts, as it can reduce the learning curve. Toasty starts with the feature set common to all database types and then adds database-specific features on an opt-in basis.

Not every data store can efficiently handle every type of query. For example, since a three-way join wouldn’t work efficiently with Cassandra, Toasty won’t allow that operation at all with Cassandra, Lerche said.

“I think it makes sense. for a Rust library that aims to focus on ease of use,” he said. “So let’s start with procedural macros. So procedural macros with Rust let you, as a library author, write a function that generates code for your user at compile time. It enables a lot, and I think is one of Rust’s superpowers. It can unlock tons of productivity when used well.”

Router with Rust

While still in development, Apollo’s new query planner in its router offers significant boosts in performance thanks to how the new code is written in Rust, according to Apollo. DeBergalis described it during the GraphQL Summit keynote as a complete ground-up rewrite of the query planner inside Apollo Router. “Thank you, JavaScript — you served us well,” DeBergalis said.

For background, query planning is the computer science inside the router that turns a query into an execution plan, DeBergalis said.  “You can think of it as the brain or the air traffic controller within the router,” DeBergalis said.

Natively written in Rust, the query planner is “significantly faster,” DeBergalis said. The native approach also allows for real multithreading, which is very difficult to achieve in a JavaScript environment.

“One thing that hasn’t changed is the algorithm itself,” he said. “This is a faithful reimplementation of the existing query planner and its semantics.”

Previously, as federated graphs gained momentum, Apollo needed to ensure that the query planner’s runtime was significantly scalable and secure. With customers running thousands of routers in their fleets with supergraphs that have over 100,000 unique operations executed at any given time, it was time for a change to create an improved query planner for such needs.

“The router is written in Rust because there’s no better language for performance-critical infrastructure,” DeBergalis said.

DeBergalis noted performance improvements such as how the median execution time of the query planner (the time it takes to go from a query to a plan),  benchmarked on over 200 representative workloads, improved by more than 10-fold. Some customers have seen over 20x improvements, while other workloads have seen less than 10x, DeBergalis said.

“Just to be clear: we’ve gone fully native in the router now—no more JavaScript. But that doesn’t mean you need to write in Rust,” DeBergalis said. “You can still extend the router in the programming language that makes sense for you, using those extensions to integrate the router into your own environment and to meet your specific needs.”