Finding a just-right job or finding a just-right person to fill a job are no easy tasks. They never were, but things are even more complicated–and the stakes even higher–in today’s constantly churning and increasingly uncertain business and global environment.
This is where Glassdoor comes in for millions of unique monthly visitors. Glassdoor has databases of millions of job listings and reviews, salaries and insights. The company is constantly looking for new ways for developers to leverage this information to improve not only the experiences of its customers, but also its ability to provide those experiences. Case in point: Glassdoor’s rapid adoption of Apollo GraphQL, the enterprise GraphQL standard.
Why GraphQL? Glassdoor and many other companies are finding that the API status quo—REST—doesn’t work well in an environment where the demand for new apps and services is relentless (which is to say, every company that wants to be competitive). As a procedural API technology, REST requires that developers coordinate each use case ahead of time. Front-end teams must constantly ask back-end teams for new endpoints, which slows the development process to a relative crawl and puts companies at a huge competitive disadvantage.
“It’s literally a cross-content model in which you have entity types and entity IDs that you save across platforms”
Director of engineering at Glassdoor
With its declarative approach, GraphQL provides a boost to developer productivity by enabling the service layer to describe the data it has and clients to describe the data they need–and only the data they need. This “graph” model not only frees developers from having to write REST endpoints, but it also enables them to work more efficiently and collaboratively through a unified, always up-to-date catalog of all the data available to them.
This flexibility, agility and resiliency enable developers to work smarter and faster, which is what initially drew Glassdoor to GraphQL. The need for a managed, enterprise-scalable version of GraphQL is what drew Glassdoor to Apollo.
A turning point in Glassdoor’s use of Apollo GraphQL came late last summer, when the company was looking to include jobs data in a new Native Collections project that would enable users to store a variety of relevant job-search content, such as salary data, employer reviews and interview data. “It’s literally a cross-content model in which you have entity types and entity IDs that you save across platforms,” said Sankha Pathak, director of engineering at Glassdoor, in San Francisco.
At that point, Glassdoor had been increasingly relying on Apollo GraphQL, and the company began a proof of concept with Apollo’s federation architecture.
“As we started using GraphQL in more of our solutions, we had to solve for scaling the development and deployment,” said Bhawna Singh, Chief Technology Officer at Glassdoor. “Ensuring that our core content teams could own their respective content schema while our cross-content teams could write efficient queries to pull this content was key for us to further adopt this technology, and that is what Apollo’s federated graph enabled for us.”
“As we started using GraphQL in more of our solutions, we had to solve for scaling the development and deployment”
Chief Technology Officer at Glassdoor
Testing went well on production-level hardware. “The number of calls were low, performance was high, and ‘joins’ worked great,” said Pathak.
There was one thing missing, however.
“We didn’t have was enough tracking, or the ability to trace through logs and issues,” said Pathak, who added that the lack of tracing and tracking capabilities is one of the biggest gaps in GraphQL (and one of the biggest drivers for moving to the Apollo implementation of GraphQL).
Glassdoor had set up tracing metrics for isolated queries on the content graph, but developers were not getting critical performance data for joined queries across sub-graphs. Pathak said he and his team had heard great things about Apollo GraphQL Manager (now called Apollo Studio) at last fall’s Apollo Summit and wanted to try it out for QA/stage environments.
The speed at which things moved after the summit—a matter of a few months between discussion and a signed contract—speaks to the faith that Glassdoor has put in GraphQL in general and in Apollo specifically.
“It all went very fast because we knew–based on the successes we had already seen in developer productivity and cost efficiencies–that Apollo GraphQL was the way we wanted to go,” said Pathak. “I started discussions with the folks from Apollo during the conference in October 2019; we sized everything and brought out a contract in February 2020. We’re already in production. We have automated alerting systems for whenever requests come in or volumes grow. We now have the ability to run pre-schema validation checks before committing, which is really good because that was one of the big problems we had before Federation. We also created a few extensions of GraphQL to support calling back to the last-known valid schema.”
Pathak and his team have worked closely with the Apollo GraphQL team throughout this journey–a level and quality of collaboration that is key to Glassdoor’s expanding use of Apollo tools, Pathak noted
“Apollo is very committed to helping its customers evolve and grow,” said Pathak. “We have developed a very close working relationship with the Apollo team. We talk to them almost every day, which is critical to ensuring that we can help our customers through both good times and difficult times.”
Scaling GraphQL at Glassdoor
Go inside Glassdoor’s graph architecture with Ian Moore and Deepak Gupta. They discuss how they...
Building an Adaptive Engineering Culture
Bhawna Singh, CTO of Glassdoor, and Rick Fast, VP Engineering at Expedia, sat down with Apollo...