A weekly newsletter of the best news, articles and projects about GraphQL

The team behind Pylon, a code-first framework for GraphQL API development, is excited to announce the release of its latest version, Pylon 2.0. Pylon takes a unique approach to GraphQL API development by inferring the schema directly from TypeScript code, eliminating the need for separate schema definitions. With Pylon 2.0, users can now benefit from support for multiple runtimes including Bun, Node.js, and Cloudflare Workers. Run `npm create pylon` to create a new Pylon project and experience its power firsthand.

The GraphQL ecosystem is vast, composed of tools and libraries in many programming languages, people and organizations from across the globe, and a plethora of maintainers, contributors and developers pulling them together. The primary mission of the GraphQL Foundation is to ensure that the GraphQL community is able to focus on the continued evolution of the specification, the shared contract that competitors and collaborators alike implement to enable maximal interoperability. This talk is to thank YOU, the GraphQL community, and highlight some of the heroes that have arisen to heed this call. Find out about their efforts over the last year improving our shared specifications, implementations, documentation, tooling, tests, and websites; about how you can get involved and help shape GraphQL to fit your organization's needs; about the support we have available; and about other community initiatives you may wish to avail yourself of.

At Expedia Group, we leverage a "code-first" approach with GraphQL Kotlin to deliver high quality experiences to travelers globally. This means we let our implementations drive our GraphQL schema. However, our developers have a growing appetite to agree on our schema up front before diving into implementation. This talk will explore how we shifted our architecture to use a schema-first approach within a code-first framework. Overall, I aim to dispel the notion that using a code-first solution prevents us from defining schema as a first step. I will explore the advantages of doing schema review at scale, as well as highlight an open source GraphQL-Codegen plugin we built to generate Kotlin classes and interfaces from our schema definitions. I am eager to contribute to the conversation around schema-first vs code-first, which has been the topic of several GraphQLConf talks over the past few years. This approach brings a fresh perspective and should inspire folks to incorporate a schema-first mentality into their GraphQL development cycle.

Pinterest is too large to simply “rewrite our app” to use GraphQL in one fell swoop. Even migrating an individual screen takes months, at our scale this is quite challenging, like changing a plane’s engine while flying. Is GraphQL adoption destined to be difficult for large companies? Can this process be made more incremental? Unfortunately, the answer seems to be no. It's hard to imagine how components consuming GraphQL data can coexist on a page that makes network requests to a REST endpoint. And yet, we figured it out. And we had a good time, too! We designed Relay-compatible APIs that allow us to read data either from a GraphQL store or from arbitrary objects (e.g. from Redux.) So, engineers can migrate individual components within a larger tree. These components specify the data they need using a fragment, and receive GraphQL-shaped data, regardless of whether the data came from GraphQL or REST. When a component tree is fully migrated, we're able to A/B test the REST and GraphQL endpoints, and only turn on GraphQL when we're sure doing so won't degrade any metrics. And we're about to release this to open source: adopting GraphQL on the front-end has never been easier!