How Toast's bet on Hive's GraphQL open source stack paid off at scale

Summary

Overview

With rapid growth and more than 100 feature teams building in parallel, Toast needed a way to keep their engineering fast and reliable.

Problem

Apollo’s tooling became a bottleneck. Performance issues, limited support, and vendor lock-in risks made it harder to manage a large federated setup and slowed down teams.

Solution

Toast adopted Hive’s open GraphQL Federation platform in phases: starting with Hive Console as schema registry, then introducing GraphQL Yoga and Hive Gateway. This allowed them to modernize their stack step by step, without disrupting ongoing development.

Results The move to Hive gave Toast a flexible and reliable foundation for scaling. Federation now supports 350+ micro-frontends and 80 subgraphs, while teams continue to deliver features quickly and safely.

Choosing a schema registry that scales

At the beginning of adopting federation, Toast compared the different options for a schema registry.

The main options were Apollo Studio and Hive Console.

After extensive testing, Toast chose Hive Console:

1. Reliability – Hive Console proved to have much better registry uptimes than Apollo Studio
2. It had all the features they needed while being actively growing and developing in the open
3. Fair and safe pricing that scales with their needs
4. No vendor-lock which gave them the option to individually choose the best pieces of their architecture
5. Open source, which made sure it was there for years to come (a bet that proved true) and also gave them the option to contribute features they cared a lot (example)
6. Security and compliance were paramount for Toast. Hive’s infrastructure came with industry-standard security certifications, such as SOC2 Type2, with a perfect score, providing peace of mind regarding data protection and privacy.
7. Support - Toast engineers always have direct access and close collaborations with the actual engineers that build the Hive Platform, through a shared Slack channel - not through intermediary sales/support engineers

Background

Toast was founded in 2012 with a monolithic Android POS and web application with a single database.

To keep performing efficiently, Toast pivoted to micro-services, allowing teams to move fast independently. Today they have over 100 feature teams.

For more details, read here the full story of how they successfully moved from REST to BFF to GraphQL to GraphQL Federation in order to stay efficient at huge scale - with a strong focus on productivity for individual teams and clear separation.

That article also highlights the importance of a good schema registry to move fast safely.

Gateway and subgraphs – Starting with Apollo, scaling with Hive

As they were adopting GraphQL Federation, they used Apollo’s gateway and subgraphs to do that.

As they scaled GraphQL Federation across the organization and different teams, they saw some shortcomings with their federation solution:

1. The implementations of Apollo Gateway and Apollo server weren’t well maintained, up to date, and performant enough
2. Active support from core developers of the platform was lacking, including responses to feature requests and raised issues

Gradual migration path

Thanks to Hive and The Guild’s open-source tooling, it was possible to gradually migrate the federated architecture, piece by piece, and only when necessary.

For most companies, the first step is to migrate the schema registry and GraphQL Platform from Apollo Studio to Hive Console.

The technical transition is a one line change, and during the evaluation period, The Guild provides companies with free credits so they could send information to both platforms and compare, making sure the transition is safe first.

As Hive Console supports any gateway and router, including Apollo Gateway and Apollo Router, and also supports any subgraphs, including Apollo Server, Toast was able to use Hive Console while keeping their existing implementations.

As Toast already chose Hive Console from the start, they were good to go and could focus on the later phases of the migration when they actually felt the need.

Second phase of the transition was to migrate from the unmaintained Apollo Server to GraphQL Yoga server by The Guild, which outperforms Apollo Server in every single metric.

Third phase was to migrate Apollo Gateway to Hive Gateway, which resulted in easier maintenance, more flexibility and significantly greater performance and efficiency on Toast’s Gateway. That phase can also be done gradually and in smaller chunks.

Hive Gateway also provided Toast with access to all of Apollo’s Paid Enterprise features for free, without the need for plans or vendor lock-in like GraphQL Subscriptions, Defer and others.

Contact us to learn how you can gradually migrate from Apollo to Hive’s open platform

Tell us about your current stack and we’ll make sure to give you our unbiased opinion on how to best scale your platform using GraphQL.

The technical profile and journey of Toast

In this section we’ll cover more technical details that might be interesting for any GraphQL developer to learn and get inspired by, for their own journey.

How they got to this architecture

Initial Approach

Toast had a long evolution to get to where they are today. Some of it was already discussed at the beginning of the article, but to expand a bit, they started with one big REST BFF, which grew into 30-40 REST BFFs. They first started GraphQL BFF at the guest side. It began with a SPA that had a Node BFF written in GraphQL. Later, the restaurant admin side also discovered GraphQL, used the same structure and added 30–40 GraphQL BFFs — each team had their own REST API (Kotlin) with a Node GraphQL BFF on top.

As more teams, like the Mobile app, needed the same data from multiple BFFs, that led them into adopting Federation and the federated graph, still using the same model where each team feature had their own REST API (Kotlin) and Node GraphQL BFF on top. Federation proved to be a great bet, growing rapidly into the company. Not only on the restaurant admin side, it was also extended to Guest side, all of them were using GraphQL Federation as their frontend API gateway, which helped them to bring consistency within all their platforms, including ToastNow their native mobile application – a high throughput, simpler auth solution. Also with the years, Toast also made acquisitions which merged and federated together into the Supergraph. But as Federated GraphQL BFFs grew by the numbers, that also led to logic creeping into the BFF layer.

Current Architecture

So the next evolution was for the Kotlin side of the team to gradually remove REST, replace it with GraphQL and directly federate into Hive Gateway, without the need of a Node GraphQL BFF in between.

This is the current architecture but as with all things, it is happening gradually, so there are still some Node BFFs and when there is a new functionality being added, the Kotlin team would gradually remove REST, move business logic from the Node BFF (that accumulated there for years) and expose it all as GraphQL.

So the current Hive Gateways federate a combination of Node GraphQL BFFs and Kotlin GraphQL subgraphs which are all registered into Hive Console.

Next steps for Toast and the Hive Platform team

As the Toast GraphQL teams and The Guild are working closely together, we make sure to align our roadmap with Toast’s needs.

Here are some of their future plans:

Feedback on the new public API

Since Hive released their new public API, a lot of integrations with internal systems at Toast could be made much simpler.

We are looking forward to seeing how they utilise the new API and if there are ways we can improve it to make it easier for them.

One area we know we want a tighter integration is with their internal Backstage system.

Usage reporting (OTEL, insights page, and errors)

We recently introduced a new system for gathering and managing OTEL metrics on Hive for selected customers.

This also affects Hive’s current insights page, which uses the current agent and query schema coordinates to show valuable data for customers.

As we design these new pages, we work closely with Toast to make sure we take their needs into account on the new design.

New and improved alerting and webhooks system

Based on the above features, we are currently in the process of redesigning our alerting and webhooks system.

There are a lot of options here so we work closely with Toast to make sure we are covering everything they need in the best way possible.

Schema proposals

Hive is close to shipping the first version of schema proposals to selected customers for feedback.

Toast is excited to try it out and see how it would best fit and improve their current schema change processes.

Progressive override

An important Federation feature that allows gradual migration of features from one subgraph to another.

As Toast is migrating types and fields from the current Node GraphQL BFFs to the Kotlin subgraphs, this becomes important for them.

New laboratory rebuild

Hive is in the process of completely rebuilding our laboratory experience.

We’ve hired a few people who built that experience on other platforms and are now bringing that knowledge into a new, improved experience.

Toast gave us tons of valuable feedback and we hope to get an exciting new experience to them very soon.

MCP and AI integrations and use cases

Toast is very forward-looking and already has tons of AI use cases, both internally and customer facing ones.

We work hard to make sure they get everything they need for these use cases from their API layer.

That includes reviewing existing solutions, finding the missing points and supporting those in our platform.