PayPal recently published a blog post describing PayPal's adoption of GraphQL over the recent years. It started with a single Checkout application in 2018 and amounted to creating a unified federated API with GraphQL federation. The adoption of GraphQL across the organisation promoted increased developer productivity and faster application shipment.
Shruti Kapoor, a senior software engineer at PayPal, describes GraphQL's current status at PayPal:
Today, GraphQL is being used by several production apps across PayPal. It is now a default pattern to use GraphQL for building new UI apps. Many existing apps are in the process of migrating to GraphQL. GraphQL is being used by common platforms such as Identity, Payments, and Compliance to provide a consistent experience across all PayPal products. Our API developers have started using GraphQL to build APIs. Braintree released its public GraphQL API.
Over the years, PayPal built tooling and standards to support GraphQL adoption in the organisation. It established a GraphQL standard for naming conventions, GraphQL types, header standards, directive standards and error handling techniques. Its tooling includes shared libraries, templates, samples, and learning resources. Also, PayPal nurtured an internal GraphQL community via a dedicated Slack channel.
PayPal is now building a single, uniform graph gateway using Apollo Federation. A similar solution was previously implemented by Netflix as well. As part of this effort, some backend development teams at PayPal decided to use GraphQL to expose their API due to perceived productivity advantages. This trend is also shared by Netflix, where engineers embraced GraphQL microservices for rapid application development.
Kapoor reports that PayPal sees many advantages with using GraphQL. A primary benefit is developer productivity. Tools like GraphiQL and Playground help increase productivity by allowing developers to play around with the API and explore documentation. Increased productivity, in turn, helps shipping faster. Kapoor elaborates:
We were able to get rid of a lot of plumbing that made it harder to provide feature updates and keep feature parity. Before, we had to ship out an SDK in every language that our merchant worked in. Now, we can provide one single GraphQL endpoint that merchants can integrate with no matter which language they use.
At the same time, PayPal encountered challenges with adopting GraphQL. One challenge is the lack of standardisation in GraphQL, "which leads to duplicated efforts across teams, different ways of handling and surfacing errors, and deviation from the standard method of handling authentication." Another challenge is the need to adapt internal tools built for REST to handle GraphQL queries appropriately.
PayPal started using GraphQL when it built its Checkout app with GraphQL. The app's development team saw the advantages of using GraphQL and evangelised them to the organisation.
Similarly, Kapoor recommends other organisations who want to start adopting GraphQL to build a demo app first "that can demonstrate how GraphQL can fit in your enterprise architecture." Then, she recommends transferring the knowledge to others, highlighting the benefits of GraphQL. Kapoor also suggests setting up your enterprise for success by creating a working group to help establish standards and provide guidance and learning resources.
GraphQL is an open-source data query and manipulation language for APIs and a runtime for fulfilling queries with existing data. GraphQL was developed internally by Facebook in 2012 before being publicly released in 2015. It has been gaining traction in recent years as an alternative to more traditional REST APIs. Its central premise is to allow increased flexibility for frontend developers, who can query the exact dataset they need for a particular screen in a single operation.
Community comments
Oh productivity
by Mac Noodle,
Oh productivity
by Mac Noodle,
Your message is awaiting moderation. Thank you for participating in the discussion.
Productivity in and of itself is not a valid measurement. What is productive for one is not for another. Initial productivity is not a guarantee of long term productivity. In fact, it typically is not. See "we use language X because it makes us productive." If you are following good engineering principles then it more than likely will be long term.
TCO is important. We will see if it is productivity long term.
We learned that writing queries in the client was not good. We learned the same in "service code". We learned that retrieving all the data from the db if you only need a little was bad. We learned that exposing your internal entities/graph was bad. We learned that only exposing what is actually needed was good.
Your choices are not REST or GraphQL. There is something better, TCO wise.