Articles
In "Demystifying GraphQL Subscription Testing: A Step-by-Step Tutorial" by Shivam Bharadwaj, developers can learn how to effectively test GraphQL subscriptions. The article provides a comprehensive guide on the process, starting with setting up a testing environment and creating a subscription schema. It then delves into topics such as mocking dependencies, handling concurrent requests, and verifying subscription logic. The author emphasizes the importance of testing GraphQL subscriptions, highlighting common pitfalls and challenges that can arise during development. By following this step-by-step tutorial, developers can ensure their GraphQL APIs are robust and reliable, providing a seamless experience for users.
In "A Detailed Guide to Performance Testing GraphQL and WebSocket APIs with JMeter" by Mahtab Haider, developers can learn how to optimize the performance of their GraphQL and WebSocket APIs. The article provides a hands-on guide on using Apache JMeter to simulate a large number of concurrent requests and measure the API's response time, throughput, and error rates. The author explains how to configure JMeter for GraphQL and WebSocket testing, including setting up request bodies, headers, and variables. Additionally, the article covers common pitfalls and best practices for performance testing, such as handling authentication and rate limiting, making it a valuable resource for developers looking to ensure their APIs can handle high traffic and user loads.
Tools & Open Source
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.
Videos
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!
