GraphQL vs. REST choice steers microservices development
GraphQL vs. REST: That is the question as teams tackle microservices architecture design, and at Pantheon, the choice came with both business boons and technical debt.
The choice to use schema-first development with GraphQL vs. REST API-driven development has laid the groundwork for all future microservices architecture decisions at a major web hosting firm.
The firm, San Francisco-based Pantheon Platform, specializes in hosting services for WordPress and Drupal sites. Three years ago, the company wanted to take advantage of the emerging microservices trend, but its engineers needed a distributed, backward-compatible 'source of truth' to coordinate microservices communications. But such a tool also couldn't place an undue burden on product teams every time they updated individual apps and services.
"GraphQL protects the front end from the back end, so the back end can change data structures quite a bit, and the front end just asks for what it needs," said Michelle Krejci, service engineer lead at Pantheon.
GraphQL was the best fit to solve that problem, Pantheon determined. It's based on a graph database protocol, which was originally the domain of webscale behemoths such as Facebook. The social media giant developed GraphQL in 2012 to manage complex sets of relationships between users and their networks of friends.
In the last three years, however, similarly complex interconnections between microservices have made graphs relevant for a broader set of companies, such as Netflix, IBM and online learning firm Coursera. Industry experts expect graph databases to catch on among enterprises in general, and GraphQL for front-end developers in particular, in 2020.
Pantheon chose Apollo GraphQL Server, a federated GraphQL platform designed for developers who want to use graphs to manage communications between services. Apollo GraphQL serves a function similar to a RESTAPI gateway for Patheon, but replaces REST API language with a GraphQL schema. Pantheon's deployment of Apollo GraphQL remains a work in progress, but ultimately, Pantheon engineers believe that GraphQL will offer greater network efficiency, support finer-grained queries on relationships between objects, build in monitoring endpoints and most importantly, decouple back-end from front-end development.
"A schema is code and its own documentation," Krejci said. "It's not just, you know, a Wiki page that no one will ever refer to -- literally writing it is creating its implementation and making it available."
Once the GraphQL schema is created, both front-end and back-end developers can start their development cycles and test against that schema in parallel.
"[That's] not something we could do with API-first development," Krejci said. "We had to wait for someone to build the API after they [designed] it."
GraphQL vs.REST pros and cons for microservices architecture
GraphQL vs. REST pros and cons
The benefits of GraphQL vs. REST also include certain microservices security advantages, according to Krejci.
"[GraphQL] meets a lot of our goals around authorization, and our desire to, as our CTO David Strauss would say, solve the 'confused deputy problem' once and for all," she said. This refers to a failure pattern in which an authorization routing path becomes overwhelmed with requests and begins to erroneously authorize requests that don't actually have adequate privileges.
Moving things from REST into GraphQL opens up a whole new paradigm of thinking about data and contracts.
Michelle KrejciService engineer lead, Pantheon
"Moving things from REST into GraphQL opens up a whole new paradigm of thinking about data and contracts," Krejci said. "What does it mean to sell a request and part of a request, and what is the contract now between the client and the back end?" Smaller, more precise requests in such a system are less likely to overwhelm authorization routing paths.
However, GraphQL has its shortcomings, such as the fact that it can't use HTTP caching in web and mobile browsers, or use familiar HTTP status codes, such as 403, for when an access request is forbidden, or 404, which pops up when a resource is unavailable. For Pantheon, the major downside of GraphQL vs. REST is the steep learning curve for developers already well-versed in REST concepts, including HTTP status codes, as they adopt new coding methods for graph schemas.
"We've actually acquired another piece of technical debt in my mind, which is adopting a bleeding-edge technology like GraphQL," Krejci said. "We have blown our innovation budget for the next couple years."
This means that while other microservices architecture approaches such as service mesh are all the rage, including within the Google Kubernetes Engine cloud infrastructure Pantheon uses, it's on the back burner while the company devotes developer resources to GraphQL.
However, GraphQL remains the wisest decision, in Krejci's mind, because of the way it facilitates conversations between business managers, product designers and software developers, without requiring tight coupling between various services and underlying infrastructure resources.
"For the most part, we can all work within our domains without needing to look around, and we've built a lot of tooling to make that possible," she said. "Service mesh would require the cooperation of all kinds of teams that have different ways of integrating with that system."
