Platform
Pricing

THE APOLLO PLATFORM

An integrated solution to take you from a POC to a centralized graph, across thousands of engineers.

Learn more

REQUEST A DEMO

Tools for collaboration, observability, federation, and more.

See how we can help

APOLLO STUDIO

Develop

A central access point and hub for your team to stay up-to-date.

Deliver

Automatic tests for breaking changes in CI, and more.

Observe

Full insight into exactly how your graph is being used.

OPEN SOURCE

Apollo Client

Manage your full app's state and connect to queries seamlessly.

Apollo Federation

A single data graph composed from multiple underlying services.

Tooling

Devtools and editor extenions for support directly in your workflow.

DEVELOPERS

Hands-on Training
Tutorials
EventsNEW

FEATURED EVENTS

GraphQL Summit Worldwide

Enterprise

Learn more about how we can help you make one uniform graph for your entire organization.

Learn more

Customers

Learn how Apollo is transforming the way industry leaders build apps.

Case studies

Guide

Read Apollo’s guide to scaling GraphQL in the Enterprise

GraphQL at Enterprise Scale

Security

Get in touch with us to request our SOC2 certificate.

Get in touch

ABOUT US

Leadership
Open Positions
Sign inCreate Account

OkCupid boosts product delivery velocity using the Apollo data graph platform

KEY STATS

170k
requests per minute
227+
entities in the graph
50%
increase in experiment velocity (YoY)

OkCupid, a multi-platform dating app, helps its users navigate the challenges of virtual dating by providing match recommendations based on deep and meaningful criteria. Maintaining a best-in-class user experience is key to their mission of making online dating easier, and in a rapidly changing industry, that means OkCupid’s engineering teams need to be able to stay agile and deliver features that drive value as quickly as possible.

OkCupid has remained a leader in their space since being founded in 2004; however, with the platform improving and expanding beyond web to iOS and Android (which it did in 2009), API development behind the scenes became increasingly complex, making it difficult for product engineering teams to move quickly. "Every product feature and any product development required a bunch of API changes," said Michael P. Geraci, Staff Web Engineer at OkCupid. "[With REST], you would have endpoints that were really bespoke to product features. The API phase would take at least a week of work before our clients got anything in their hands."

With the scalability of their REST model hitting a breaking point, OkCupid needed a solution to reduce one-off API endpoint requests and unblock client teams. "In looking for what to replace our 7-year old REST API with, we wanted a solution that had wide adoption, robust tooling and community support, and would serve OkCupid for a similarly long time," Geraci explains. Apollo’s data graph platform provided just that, and it has allowed their teams to decouple feature delivery for clients from API development, driving greater team efficiency and increased experimentation velocity.


A better way to migrate to GraphQL

Of course, the process of moving from REST endpoints to a common data graph didn’t happen overnight. Before OkCupid could migrate, they needed to ensure that the GraphQL endpoint could perform just as well as existing REST endpoints. And at first, it didn’t.

To compare the performance of the new GraphQL API to the previous REST API, the OkCupid team ran an experiment. "We released what we called The Shadow Request," Geraci explains in his post on the OkCupid engineering blog. "On our target page, the user loaded the page's data from the REST API as normal and displayed the page. Then, the user loaded the same data from GraphQL, measured that call’s timing, and discarded the data. we discovered that our first release of the GraphQL API took about double the time — 1200ms versus 600ms — of the REST API. If we had shown this version to real users, it would have led to a very poor experience for them."

Using the trace view in Apollo Studio, Geraci and his team discovered that the resolver was making 20 cascading requests to the back end:



By simply updating the resolver to batch these requests instead, they were able to reduce the duration of the call by nearly 275ms:



"The tracing in Studio was critical to troubleshooting that first release," Geraci recalled. With the new GraphQL API performing well, OkCupid was then able to release it in full to their client teams, creating opportunities for developers to improve the platform.


Freeing client developers


As the engineering manager for the Android team at OkCupid, Joe Acosta was very familiar with the slowdowns caused by old REST APIs. "Before we switched over, API development was the main blocker for us in terms of our product process," said Acosta. “Whatever feature we were doing, it usually meant developing a brand new API.” Geraci, whose team was responsible for implementing any API changes agreed — "Any sort of new feature required a bunch of REST API changes — new endpoints or weird versioning issues or wanting new data for different experiments, all sorts of little things like that." For every engineering team at OkCupid, enabling more democratized access to data had become a top priority. The Apollo data graph allowed them to do just that.

Apollo removes a roadblock for a lot of app developers and just lets them focus on what they love to do.
Joe Acosta

"From a developer experience point of view, it's definitely been a win because I've seen the native app teams develop features without really needing changes from the graph," says Geraci. An early victory, he recalled, was enabling the app teams to start natively rebuilding the user profile page without any API changes — they were able to do so by simply reusing data that already existed in the graph. "With the graph, it's an assembly of pieces that are already there," he explains. "I made the schema change required for messages, and native app developers could do the same thing on their side, that's expected. But to get the messages page, I needed to make a user entity, and the user has a display name and a photo and an age. Just having those things in the graph made it possible for the app teams to start nativizing the profile page by converting the data source for that to the graph. And that was without my involvement at all."

For Acosta’s team, the adoption of Apollo’s data graph platform was a revelation. Where before developers were waiting on new REST endpoints, they could now begin development on new features immediately. "Sometimes it doesn't even require new asks to work on a new project," he explained. "Apollo removes a roadblock for a lot of app developers and just lets them focus on what they love to do."

In addition to simply unblocking client developers, the Apollo data graph has also helped them explore and consume data from the back-end in a more self-serve manner, enabling them to create and act upon new ideas in a way that was not possible with REST endpoints. "I think Apollo affords client developers a lot of freedom that other tools don't to build out queries yourself and play around," said Acosta. "It's less of a black box to us because we have that window into what's actually available."


Increasing experimentation

The data graph helped accelerate OkCupid’s delivery velocity, especially their ability to experiment more frequently. "We have a pretty robust experiment system — a whole dashboard that allows product managers, engineers, and designers to create experiments," Geraci explained. With the adoption of the graph, Geraci was able to make the experimentation system self-serve for client developers. "I added the ability for clients to query for a particular experiment and what group you'd be in,” he continued. “That paired with the fact that we had a user-friendly dashboard allowed client developers, all of a sudden, to run their own experiments without any API changes. That unblocked a whole host of things that clients wanted to do that they never really got to do because it would have involved bugging the web team."



Within one year of adding the ability to query for experiments to the graph, the average number of experiments run by the OkCupid engineering team increased by 50%. "It’s safe to say that the pace of experimentation increased at that time, and it's from the addition to the graph," said Geraci. "I think it was a really unexpected and surprisingly large win."

Moving forward, OkCupid expects to expand the use of the graph and encourage more of its developers to begin contributing to it. "We're pushing client devs to get more exposure to actually add stuff to the graph," said Acosta. "I think one great thing about it is that it's something pretty much everybody gets excited about. Now, everything new we build, we use Apollo and can build it with GraphQL."



A multi-platform dating app that helps users match on what matters to them in order to find meaningful connections.

CHALLENGE

Many bespoke REST endpoints for specific product features. API development was the main blocker for product development progress.

SOLUTION

Apollo data graph to unify application data and decouple client teams from API development.

RESULTS
  • Agile product development teams with increased delivery velocity
  • Improved performance metrics and optimizations
  • Over 50% increase in experiment releases after adopting Apollo’s data graph

Questions?