OkCupid boosts product delivery velocity using the Apollo graph platform

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 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 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 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 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 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 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.”