# Graphql > title: Recapping our latest Q&A Session - Scaling UI Development with Relay GraphQL --- --- title: Recapping our latest Q&A Session - Scaling UI Development with Relay GraphQL tags: ["blog"] layout: blog date: 2023-07-19 byline: Jory Burson permalink: /blog/2023-07-19-hasura-qna-recap --- On July 12, we hosted an an enlightening Q&A session on scaling UI development with Relay GraphQL. Participants included several experts from [Hasura](https://hasura.io/) as well as interested attendees from our Discord community. The Q&A session was all about discussing the power of Relay in the realm of UI development. [Tanmai Gopal](https://www.linkedin.com/in/tanmaig/), CEO of Hasura, and [Akshaya Acharya](https://twitter.com/_nullxone), developer at Hasura, led the conversation, sharing their experiences and knowledge about the utilization of Relay and GraphQL in managing UI projects. For those who couldn't make it, we've captured the highlights and insights shared during the discussion. Read on, and join us for our next Q&A Session on July 26 for another discussion about GraphQL at Scale on the [GraphQL Community Discord](https://discord.graphql.org) server! 1. **Scaling UI development with Relay GraphQL**: The Hasura team discussed how Relay GraphQL can facilitate scaling UI development, emphasizing how it can be a practical solution to prevent in-house development of similar mechanisms. 2. **Relay and React Server Component (RSC)**: They discussed their learnings from comparing and trying Relay with React's next-gen features like RSC and server actions. They pointed out that Relay fits well into things like RSC and solves issues that RSC alone does not handle, such as "compose API fetching across different types of components and craft the best / minimal set of queries." 3. **Migration to Relay**: The Hasura team shared their ongoing experience of migrating existing UI to Relay to improve team productivity. They emphasized the need to introduce Relay in independent and then closely connected components to avoid data inconsistency issues. 4. **Nullable-by-default schema with client controlled nullability**: The team also discussed the idea of using a nullable-by-default schema with client-controlled nullability. They noted that, while this approach can solve problems related to resolver errors and changes in the data model, it requires careful handling on the client side. 5. **Integration of Relay with NextJS**: Examples were shared on how to integrate Relay with the NextJS App Router and NextJS Pages Router. 6. **Development Tools for Relay**: They showed interest in the tools the community is using to build a backend Relay server, and the challenges faced while working with Relay. 7. **Relay and backend practices**: The Hasura team mentioned that they have not enforced nullable-by-default schemas yet and they can handle breaking changes rapidly due to their ability to iterate quickly on their GraphQL server. The discussion provided valuable insights into how Relay GraphQL can ease and scale UI development. Notably, the real-world experiences shared by the Hasura team brought home the potential and practical advantages of using Relay in handling large-scale UI projects. For those who missed it or wish to revisit, the [full transcript](https://discord.com/channels/625400653321076807/1098318659727921275/1128737562412974211) is available on our [Discord channel](https://discord.graphql.org). Stay tuned for more such interactive Q&A sessions about modern topics and opportunities with GraphQL. If you have an idea or request for a Q&A session, please let us know! --- --- title: "Welcoming Yaacov Rydzinski to the GraphQL.js Maintainer Team" tags: ["announcements"] date: 2024-10-14 byline: Jory Burson and Benjie Gillam --- We are thrilled to announce a new co-maintainer of GraphQL.js: Yaacov Rydzinski [@Yaacov Rydzinski](https://github.com/yaacovCR) has been approved as a co-maintainer of GraphQL.js! Yaacov’s journey into open source and GraphQL is unique, having earned degrees in both Medicine and Computer Science. Whereas most maintainers are employed as software developers, Yaacov is a radiologist by day and star GraphQL contributor by night. Yaacov brings real-world, end-user experience building APIs and tools for the medical field - sounds like a superhero to us! GraphQL.js is a fundamental library in the GraphQL ecosystem, serving as the reference implementation of the GraphQL specification in JavaScript. It provides the essential building blocks for defining GraphQL schemas, executing queries, and validating data, making it a critical tool for developers building GraphQL APIs. As the backbone of many GraphQL-based applications and services, GraphQL.js plays a pivotal role in driving the adoption and evolution of GraphQL technology across the web development community. The GraphQL.js maintainers ensure the project's health by managing contributions, reviewing code, addressing issues, and guiding its evolution. Their role is vital in maintaining the quality, security, and relevance of the software, fostering a collaborative environment, and engaging with the community. Please join us in welcoming Yaacov to the GraphQL.js team, and join us for an upcoming [GraphQL.js Working Group](https://github.com/graphql/graphql-wg?tab=readme-ov-file#subcommittee-meetings) meeting! --- --- title: "Call for Participation for FOSDEM API & Friends devroom" tags: ["blog"] date: 2024-11-04 byline: Jem Gillam --- We are excited to announce the [Call for Participation for the FOSDEM 2025 APIs: GraphQL, OpenAPI, AsyncAPI & Friends Devroom](https://pretalx.fosdem.org/fosdem-2025/cfp). ## What is FOSDEM? [FOSDEM](https://fosdem.org/) is a two day, free and non-commercial event held in Brussels, Belguim, in February each year. It brings together over 8,000 software developers to meet, share ideas and collaborate on free and open source software. The FOSDEM team feel it is very important that developers get to meet offline and so run Devrooms to facilitate this - rooms with talks, panels and showcases centered around one theme where developers can share ideas and publicly present their latest findings, news and projects in a collaborative atmosphere. ## What is the APIs & Friends Devroom? A platform for developers, technologists, and enthusiasts to come together to discuss, learn, and collaborate on topics around APIs and Open Source. Open collaboration is a driving force behind APIs and open-source projects, and we look forward to talks on community-driven technologies such as OpenAPI, GraphQL, AsyncAPI, gRPC and webhooks. ## Suggested Topics We welcome submissions about, but not limited to: - Your favourite Open Source project: tooling, frameworks, SDKs, API gateway, etc. - Topics related to API standards such as OpenAPI, GraphQL, JSON Schema or AsyncAPI. - API Design Principles: best practices for designing clean, efficient, and developer-friendly APIs. - Topics related to versioning, authentication, rate limiting, and error handling. - Real-world API Use Cases. - Developer Experience and API Documentation. ## Important Dates - Sunday Dec 1st 2024: Submission deadline (Closes at midnight Brussels time) - Sunday Dec 15th 2024: Announcement of selected talks - Sunday Feb 2nd 2025: Devroom at 1pm, in person at ULB Solbosch Campus, Brussels, Belguim ## Recording Please be aware of the fact that, barring any technical difficulties, devroom talks at FOSDEM will be recorded. By submitting a proposal you agree to be recorded and to have your talk made available from the FOSDEM video platform. ## How to submit a talk - Talk submissions can be 20 to 25 minutes, allowing a short Q&A time to fill the rest of the 30 minute slot - Shorter (lightning) talks should be 10-12 minutes and should indicate "lightning talk" in the description - Go to [FOSDEM pretalx](https://pretalx.fosdem.org/fosdem-2025/cfp) website - Select ‘APIs: GraphQL, OpenAPI, AsyncAPI, and friends’ from the ‘Track’ field ## Code of Conduct The code of conduct for FOSDEM is available at https://fosdem.org/2025/practical/conduct/ ## Questions You can reach the devroom organisers at: api-devroom-manager AT fosdem.org The APIs: GraphQL, OpenAPI, AsyncAPI & Friends Devroom is organised by volunteers who also ran the API & Friends devroom last year, and joining forces with members of the GraphQL Technical Steering Committee to bring a GraphQL focus as well as fostering collaboration with folks representing OpenAPI and AsyncAPI projects. --- --- title: "Learn Documentation Update, October - November 2024" tags: ["grants"] date: 2024-12-12 byline: Mandi Wise --- > The GraphQL Foundation offers [Community Grants](https://graphql.org/foundation/community-grant/) to help incentivize key technical and community initiatives. As part of the grant, applicants commit to write a blog post report describing their work and its impact on the GraphQL community. The following report was written by successful grant applicant Mandi Wise in November 2024, detailing the documentation updates she submitted during October and November of that year. ## The opportunity The [Learn documentation](https://graphql.org/learn/) has been a key resource on this site since its launch. And because of their search engine ranking, the tutorial pages are often one of the first stops for someone starting their GraphQL learning journey. They're also a great resource for those already working on GraphQL projects who want to ensure they implement best practices. The Learn docs have undergone some maintenance and iteration since their initial publication, but there were [some long-outstanding tasks](https://github.com/graphql/graphql.github.io/issues/41) for this section of the site, as well as several open docs-related issues in the repository that had been submitted by community members. I have some experience teaching and writing about GraphQL, so in late August, I decided to submit a proposal to the [GraphQL Community Grant](https://graphql.org/foundation/community-grant/) program so I could make a focused effort to address a collection of the open issues, as well as fill in some other content gaps that had emerged as the specification has evolved and certain best practices have become well-established in the community. The grant application was approved by the GraphQL Foundation a few weeks later into September, and I started work on the project by early October, with a goal of completing the work by the end of November. ## Doing the work The scope of my approved project was to review and edit most of the pages in the Learn section of the site, create several new pages, and split some of the existing pages into more focused topics with expanded content. After my proposal was approved, I further refined the scope of this work by completing a more detailed content audit that was reviewed by members of the GraphQL TSC before I proceeded. Now that the work has been completed, some notable changes include: - A new and improved [landing page](/learn/) for the docs - Dedicated pages for [Queries](/learn/queries/) and [Mutations](/learn/mutations/) with additional examples, plus a new [Subscriptions page](/learn/subscriptions) - A new [Response page](/learn/response/) with content about data and error formats - An overhauled [Serving over HTTP page](/learn/serving-over-http/) so that it aligns with the [draft GraphQL over HTTP specification](https://graphql.github.io/graphql-over-http/draft/) - New pages in the Best Practices section covering [Performance](/learn/performance/) and [Security](/learn/security) topics In addition to these content changes, I also standardized the page formatting with subtitles and summaries, made some additions to the SWAPI schema to support the new examples in the docs, and made a quality of life improvement to the mini GraphiQL component to add labels to each of the panels in the editor. To complete this work, I submitted PRs to the [graphql.github.io repo](https://github.com/graphql/graphql.github.io) and I typically sent one PR per docs page to keep the review process manageable. This approach also allowed us to incrementally release updated pages to the site when they were ready. In total, I submitted 12 PRs that addressed 8 open issues in the repository. Refining and publishing the docs content was a collaborative process, and I'd like to give a big shout-out to [Benjie Gillam](https://github.com/benjie) for the time he committed to reviewing all of my PRs and providing feedback throughout this process. I'd like to thank [Uri Goldshtein](https://github.com/Urigo), [Saihajpreet Singh](https://github.com/saihaj), [Eddy Nguyen](https://github.com/eddeee888), and [Dimitri POSTOLOV](https://github.com/dimaMachina) for their feedback during this project too. ## What's next? The Learn docs have been broadly updated now, but there's still potential for additional enhancements. Some ideas that were discussed but that ultimately fell outside the scope of this project included new pages on trusted documents, composite schemas, and migrating from REST, as well as developing expanded content for the existing Caching page. If you're interested in any of these topics, I'd encourage you to send a PR or even [submit a grant proposal](https://graphql.org/foundation/community-grant/) too if you're inspired to take on a larger project. Feel free to reach out to me on Discord (@mandi.wise) or [Github](https://github.com/mandiwise/) and I'd be happy to provide input or help. --- --- title: "Welcoming New TSC Members" tags: ["foundation"] date: 2025-02-05 byline: Lee Byron --- The GraphQL Technical Steering Committee is the body responsible for the technical oversight of all our open source projects and management of our open source community. Every year we vote on self-nominees to rotate up to half of TSC members, and we've just concluded the most recent vote. ### Our new TSC elections... I’m excited to share that we have elected two new members to the GraphQL Technical Steering Committee (TSC), [Martin Bonnin](https://github.com/martinbonnin) and [Pascal Senn](https://github.com/PascalSenn), technical leads at Apollo and ChilliCream respectively. They have been consistent contributors to the GraphQL open source project over the last few years and I'm thrilled to have their help in and commitment to guiding and advancing the GraphQL technical project and broader ecosystem. In addition, we also re-elected three existing members, [Kewei Qu](https://github.com/Keweiqu) a technical lead at Meta working on the original GraphQL deployment, [Rob Richard](https://github.com/robrichard) an engineer at 1stDibs and the lead of the Streaming GraphQL project, and [Uri Goldshtein](https://github.com/urigo) founder of The Guild. These all join our existing [TSC members](https://github.com/orgs/graphql/teams/tsc/members). ### Open working groups and the role of the TSC GraphQL is an open project. All are welcome to join our [working group](https://github.com/graphql/graphql-wg/) meetings, champion proposals for project-wide improvements, or contribute directly across our open source projects. It has been critical to keep access to these working groups open, but it does mean a rotating cast of contributors over time. The primary role of the TSC is to provide continuity as the stewards of this group and our processes, and co-owners of our technical projects. While the TSC is a closed group, our focus is always on strengthening the work that happens in our open Working Group meetings—that is where technical work moves forward. ### Our processes To learn more about the TSC and how we work, check out these resources: - **[2025 TSC Elections](https://github.com/graphql/graphql-wg/issues/1612)** — we use Github issues for most things across the Working Group and TSC, and this one tracked the TSC election itself. Anyone could self-nominate via a Google Form, and we held a vote via OpaVote. - **[TSC Charter](https://github.com/graphql/graphql-wg/blob/main/GraphQL-TSC.md)** — this lists out in detail how the TSC is governed, which contains more detail about when and how we take votes, and what we're accountable for. - **[GraphQL Working Group](https://github.com/graphql/graphql-wg/)** — this is where we organize meetings and contribution across the Working Group, where you'll find past and upcoming agendas and can join an upcoming meeting simply by adding yourself to the next agenda file in a PR. I'm beyond lucky to get to work with such a talented group of volunteers both directly on the TSC and across the GraphQL community. Welcome, Martin and Pascal! — Lee --- --- title: March 2025 GraphQL Foundation Board Meeting Recap tags: ["foundation"] date: 2025-04-18 byline: GraphQL Governing Board --- _Note: The GraphQL Foundation Governing Board will be authoring monthly blog post summaries of their meetings. This is the first approved post, with more to come!_ GraphQL Foundation’s Governing Board gathered on March 20 for a productive meeting focused on transparency, community growth, and continued technical progress. One key highlight was the board’s support for hosting **biannual public “Town Hall”–style meetings**, inspired by the first such meeting at GraphQLConf 2024. These events—one of which will be held during GraphQLConf 2025 in September—aim to bring more visibility to the Foundation’s work and encourage community participation and input. On the technical front, the **Technical Steering Committee (TSC)** shared updates on nullability, upcoming changes to graphql-js, and ongoing work on the incremental delivery specification. The team also encouraged feedback from Board Members and the community on behalf of GraphQL over HTTP. The new [**Community Working Group**](https://github.com/graphql/community-wg), under the TSC, reported strong early engagement, including work on a refreshed GraphQL.org landing page and an open, async collaboration model based on GitHub issues. The **Marketing & Content Committee** reported that efforts are underway to produce a series of case studies and better support industry-specific adoption stories. The team is also exploring more tailored messaging and additional social media campaigns to promote the conference, Local initiatives, and GraphQL-related news. Preparations for GraphQLConf 2025 in Amsterdam are well underway. The CFP has seen increased submissions compared to last year, and new voting tools will enable more inclusive talk selection. Ticket sales are tracking to plan, and the Foundation is actively seeking additional sponsors to support the event. Finally, the **Budget Committee** presented a draft of a new membership pitch deck designed to better communicate the impact and benefits of joining the GraphQL Foundation. The committee is continuing to refine this deck and will solicit ongoing feedback on the messaging. Stay tuned for more updates as we continue working together to support the GraphQL ecosystem and community. If your organization is interested in sponsoring GraphQL Conf or contributing a case study, we’d love to hear from you! --- --- title: 📣 April 2025 GraphQL Foundation Board Meeting Recap tags: ["foundation"] date: 2025-05-15 byline: GraphQL Governing Board --- The GraphQL Foundation Governing Board met April 17 to discuss ongoing community efforts, technical progress, and upcoming events—read on for the highlights: ### **🖥️ Website Redesign Underway** The first version of the new GraphQL.org design is live for community feedback on [GitHub](https://github.com/graphql/community-wg/issues/21#issuecomment-2766734209)! Championed by The Guild, the new site focuses on communicating GraphQL’s value to different types of users. Check it out on GitHub and [Figma](http://figma.com/proto/aPUvZDSxJfYDJtPd7GF2sB/GraphQL.org?page-id=10%3A13019&node-id=649-3367&viewport=-2607%2C336%2C0.13&t=eZKIRpRkrWRATgQb-9&scaling=scale-down&content-scaling=fixed&starting-point-node-id=649%3A3367&show-proto-sidebar=1)—your feedback is welcome. ### **🌍 Planning GraphQL All-Hands** We had fabulous input and a great turn out for our first public board meeting, which was held at GraphQLConf 2024. We’re building on that idea with a plan to host twice-a-year **GraphQL All-Hands** sessions. These gatherings will celebrate progress, share strategic updates, and foster open discussion. The next one will take place at [GraphQLConf 2025](https://graphql.org/conf/2025/) this fall! ### **📊 Community Survey Discussion** Several Board and community members are exploring a user survey to help shape technical priorities, improve documentation, and inform event content. The Board discussed options to help the effort start small and release iteratively—stay tuned! ### **💸 Budget & Membership** We're exploring aligning our fiscal planning with GraphQLConf to better match our annual rhythm. We also celebrated progress on new community grants! 🎉 ### **🎤 GraphQLConf 2025** We’re expanding community involvement in the CFP process by becoming a **Subject Matter Expert**—we’re looking for volunteers to help rank talks for the conference program. Also, we're proud to support an [ALS charity swim team](https://graphql.org/blog/graphql-stream-team/) happening before the conference. The CFP closed **May 12**. --- --- title: Announcing graphql-js.org! tags: ["announcements"] date: 2025-06-20 byline: GraphQL-js Maintainers featured: true --- Dear Community, We're excited to share a milestone in the GraphQL-JS journey, one that puts our community at the center of everything we do. For years, GraphQL-JS documentation lived under the broader graphql.org umbrella at `/graphql-js`. While this made sense back then, we want to serve y'all better, we want upgrade guides and everything graphql-js specific to live in one easy to navigate place. We're thrilled to announce that GraphQL-JS has moved to its dedicated home at [**graphql-js.org**](https://www.graphql-js.org). This isn't simply a change of address, it's a commitment to the community that has made GraphQL-JS what it is today. This new home represents the first step in a larger mission: giving you the comprehensive documentation, clear upgrade paths, and responsive support that a project of this scale deserves. What This Means for You - **Easier discovery**: No more hunting through nested documentation structures - **Focused experience**: Everything GraphQL-JS related in one dedicated space - **Better navigation**: Documentation organized around your workflow, not our internal structure Coming soon: - **Comprehensive upgrade guides**: Clear, step-by-step paths between major versions, GraphQL V17 will be our first attempt at this - **Enhanced reference documentation**: Every API documented with real-world examples ## An Inflection Point We see this move as an inflection point, a moment where we recommit to being the reference implementation the community deserves. GraphQL-JS isn't just code; it's the foundation that teams around the world build upon. Whether you're implementing a new GraphQL server, debugging a complex schema, or upgrading between major versions, you deserve documentation and tooling that makes your job easier, not harder. This is our promise: we're not just maintaining GraphQL-JS, we're investing in its future and yours. --- _The GraphQL-JS Maintainers_ _Questions or feedback about the new site? We'd love to hear from you in our [GitHub discussions](https://github.com/graphql/graphql-js/discussions) or on the [GraphQL community Discord](https://discord.graphql.org) in channel `#graphql-js`._ --- --- title: "GraphQL.js Docs Updates, April - May 2025" tags: ["announcements", "grants"] date: 2025-06-26 byline: Sarah Sanders --- > The GraphQL Foundation offers [Community Grants](https://graphql.org/foundation/community-grant/) to help incentivize key > technical and community initiatives. As part of the grant, applicants commit to write a blog post report describing their > work and its impact on the GraphQL community. The following report was written by grant recipient Sarah Sanders in June > 2025, summarizing the documentation updates she contributed to the GraphQL.js reference guides during her project. ## About the project The [GraphQL.js](https://github.com/graphql/graphql-js) library is the reference implementation of the GraphQL specification in JavaScript, and it's widely used both directly and indirectly by many GraphQL tools and servers. While the implementation itself is robust and actively maintained, the supporting documentation had room to grow—especially when it came to helping developers understand _how_ GraphQL.js reflects the spec and _how_ to use its APIs in real projects. With that in mind, I applied for a GraphQL Foundation Community Grant to work on improving the GraphQL.js documentation. My goal was to make the guides more approachable for newcomers, more accurate for advanced users, and more aligned with the specification for everyone. ## What I worked on This project involved a full audit of the existing GraphQL.js guides, followed by targeted updates to improve clarity, structure, and completeness. I focused on areas that were either under-documented or potentially confusing, and worked to ensure the guides explained not just _what_ GraphQL.js does, but _why_ and _how_ it does it. Some key improvements include: - Clearer explanations of schema construction and how types are defined in GraphQL.js - Improved guidance on how execution and validation flow maps to the spec - Expanded sections on custom scalars and other advanced patterns - New guides on testing and production-readiness All updates are live on the [GraphQL.js docs site](https://www.graphql-js.org/docs/). ## What's next I hope these updates help more developers learn and use GraphQL.js effectively, and serve as a foundation for future improvements to the reference documentation. There’s still more we can do and I’d love to see others in the community build on this work. This project was a rewarding chance to contribute meaningfully to the GraphQL ecosystem, and I’m thankful to the maintainers who reviewed, discussed, and supported the updates throughout the process. If you’re considering a documentation or community contribution, I encourage you to explore the [GraphQL Foundation’s Community Grant Program](https://graphql.org/foundation/community-grant/). It’s a great way to go deep, give back, and help others along the way. Feel free to reach out if you’re thinking about submitting a proposal. I’m happy to share what I learned! You can reach me via [GitHub](https://github.com/sarahxsanders) or [LinkedIn](https://www.linkedin.com/in/sarah-s-42913121a/). --- --- title: 📣 May 2025 GraphQL Foundation Board Meeting Recap tags: ["foundation"] date: 2025-06-27 byline: GraphQL Governing Board --- # 📣 GraphQL Foundation May 2025 Board Meeting Recap The GraphQL Foundation Governing Board met for its monthly board meeting on May 15 to share updates across community, technical, and operational committee initiatives. Here's a quick look at what was covered: ## 🌐 Community & Website Updates Work continues on the redesign of [graphql.org](https://graphql.org), led by the Community Working Group. The new site will feature refreshed messaging, community-focused sections, and improved support for case studies. Community input is welcome via GitHub and monthly working group meetings. It’s looking great! ## 📅 GraphQL Conf 2025 Planning Preparations for GraphQLConf 2025 are fully underway! The Call for Proposals has closed, and submissions are under review with support from 16 subject matter experts from the community and the TSC. Sponsorships are coming in from members like **Apollo**, **Grafbase**, and **Meta**, and attendance targets are on track. Two new local GraphQL meetup groups have launched in India, and discussions about a potential ambassador program are in development. ## 💸 Budget & Strategy The Foundation is considering shifting its fiscal planning to align with the conference, which would simplify planning and help center GraphQLConf as a key milestone each year. Grant-funded projects are progressing well, including improvements to GraphiQL and documentation. ## 🔧 Technical Progress The Technical Steering Committee (TSC) shared updates on several fronts: - A release candidate for the new **GraphQL over HTTP specification** is nearly ready. - Key proposals like **Input Unions** and updated **deprecation rules** have been accepted into the spec. - Legacy versions of **graphql-js** have been formally deprecated, with a new versioning policy now in place. - A new **OpenTelemetry Working Group** has launched to improve observability support for GraphQL. ## 📣 Get Involved The Foundation is looking for help organizing the conference schedule, gathering community case studies, and contributing to ongoing spec work. If you're interested in supporting the ecosystem, now’s a great time to jump in! Stay tuned for more updates at [graphql.org](https://graphql.org) and follow us for the latest on GraphQLConf 2025. --- --- title: "Announcing Our GraphQL Ambassadors" tags: ["announcements"] date: 2025-09-08 byline: Jem Gillam and Jory Burson --- The GraphQL Foundation is thrilled to announce the launch of the GraphQL Ambassadors Program — a new initiative to recognize and support community leaders who are helping to grow the GraphQL ecosystem worldwide. GraphQL has long since established itself as a global standard for powering APIs across startups, enterprises, and platforms. Our incredible network of educators, maintainers, advocates, and organizers keeps the community strong and well-positioned to support developers at all stages of their GraphQL journey. We’ve launched the GraphQL Ambassadors program to: - **Highlight contributors** who are already teaching, mentoring, and building with GraphQL. - **Support local communities** through meetups, conferences, and workshops. - **Amplify voices** from across the globe to ensure GraphQL remains accessible, inclusive, and community-driven. - **Share GraphQL best practices** and gather feedback from developers. ## **Meet the First Ambassador Cohort** Ambassadors are nominated and represent a diverse range of geographies, backgrounds, and use cases — from maintainers of popular libraries, to meetup organizers, to educators writing guides and tutorials. Join us in celebrating our first group, and stay tuned for more news about this program! ![Artur Czemiel, Donna Zhou, Erik Wrede, Itamar Kestenbaum, Jeff Auriemma, Jordan Eldredge, Jovi De Croock](./group1.png) ![Michael Watson, Patrick Arminio, Dotan Simha, Sarah Sanders, Stephen Spalding, Eddy Nguyen, Warren Day](./group2.png) ![Marc-Andre Giroux, Taz Singh, Phil Pluckthun, Jem Gillam, Jamie Barton](./group3.png) ## **How to Get Involved** - **Nominate an Ambassador.** Do you know someone doing incredible work with GraphQL? [Nominate them](https://forms.gle/hN7reX8aKQ6BqSJm7) (or [yourself](https://forms.gle/zRKVfcTPQ9kFn4Ps6))! - **Connect locally.** Attend events and workshops hosted by Ambassadors in your region. - **Share your story.** If you’re publishing, teaching, or building with GraphQL, we’d love to hear from you. ## **What’s Next** The Ambassadors program is part of our broader effort to strengthen community engagement and education around GraphQL. Look forward to spotlights on our inaugural cohort, upcoming blogs and speaking opportunities, and ways you can collaborate with these leaders. Together, we’re building not just technology, but a thriving, global GraphQL community. --- --- title: "Introducing the New GraphQL.org: A Decade of Evolution, Redesigned" tags: ["announcements"] date: 2025-09-08 byline: Saihajpreet Singh & Piotr Monwid-Olechnowicz --- After ten years of continuous growth and evolution, we're excited to announce the complete redesign of GraphQL.org! What started as a simple query language has transformed into the backbone of modern API development at companies like Meta, Netflix, GitHub, and thousands of others worldwide. ## Why Now? GraphQL has come a long way since its inception. As the ecosystem has matured and adoption has scaled globally, our website needed to evolve too. The previous design served us well as we expanded, but it was time for a refresh that truly reflects where GraphQL stands today and where it's heading. ## What's New Our redesigned homepage now clearly communicates not just what GraphQL is, but why it matters for modern development: **Clear Value Propositions:** We've highlighted GraphQL's three core benefits: delivering the best user experience, ensuring security and stability, and enabling efficient distributed development. **Proven at Scale:** See how leading companies leverage GraphQL in production environments. **Use Case Guidance:** Whether you're building a mobile app, managing microservices, or developing AI-powered applications, discover if GraphQL is right for your project. **Enhanced Resources:** From the five pillars of GraphQL to data colocation patterns, we've organized our content to help you succeed at every stage of your GraphQL journey. **Community Focus:** Stronger connections to our vibrant community resources and contribution opportunities. ## Behind the Scenes: Technical Craftsmanship Beyond the visual refresh, this redesign showcases some interesting technical details that our community might appreciate: **Creative Problem-Solving:** That smooth rotation animation you'll see? It's not just for aesthetics. [It's actually the only way to animate the element without breaking the highlight effects](https://stackoverflow.com/questions/74085350/backdrop-filter-doesnt-apply-if-parents-opacity-is-less-than-1) from the underlying wire graphics. Sometimes constraints lead to the most elegant solutions. **Developer Experience:** We discovered it's faster to iterate on syntax highlighting themes in VSCode than in our Nextra-shiki setup. This led us to publish a [syntax highlighting theme](https://github.com/hasparus/k-colorable) as a side effect of the redesign process. ## Explore the New Experience The redesigned GraphQL.org better reflects the maturity and sophistication of both the specification and its ecosystem. We've maintained our commitment to clear documentation while adding the context and guidance that today's developers need. [Visit the new GraphQL.org →](https://graphql.org/) ## Get Involved This redesign represents input from our entire community. As always, we welcome your feedback and contributions. Join the conversation in our [Community Working Group](https://github.com/graphql/community-wg) and help shape the future of GraphQL. --- --- title: "Announcing the September 2025 Edition of the GraphQL Specification" tags: ["spec"] date: 2025-09-08 byline: Lee Byron featured: true --- It’s here: the [September 2025 edition of the GraphQL specification](https://spec.graphql.org/September2025/)! This is the first edition of the specification since [October 2021](https://spec.graphql.org/October2021/), and it reflects years of steady, collaborative work from the GraphQL community. More than 100 commits, hundreds of comments, and contributions from dozens of community members went into this update — all with the goal of keeping GraphQL stable, expressive, and primed for the next generation of AI-ready API development. Since its initial release 10 years ago, GraphQL has grown into a critical layer of infrastructure at startups, enterprises, and platforms across industries. The spec has two guiding priorities: **Stability first**: With so many tools and services built on GraphQL, the ecosystem relies on a solid foundation. This release fixes inconsistencies, addresses edge cases, and helps avoid performance pitfalls. **Expressiveness for API consumers**: Developers use GraphQL because it’s intuitive, flexible, and powerful. This edition makes the language even more productive and expressive, particularly for AI-first applications. ## **Why It Matters** Several updates in this edition make GraphQL an even better foundation for AI assistants, codegen tools, and autonomous agents: - Descriptions on executable documents give LLMs richer context for intent understanding and safer refactoring. - Schema Coordinates provide a precise, both human- and machine-readable way to reference fields and types, improving traceability, evals, and automated PR feedback. - OneOf input objects simplify schema entrypoints whilst maintaining type safety by expressing mutually exclusive inputs directly in the schema. This is particularly helpful for prompt and form generation. - The clarified execution/error terminology and request `extensions` make responses more predictable for deterministic parsers and toolchains. ## **Notable Updates** - **OneOf Input Objects (a.k.a. input unions)** \ A long-requested feature! This unlocks more natural ways to model mutually exclusive inputs, leading to tidier schemas and unlocking use-cases that couldn’t be safely expressed previously - check out the [blog post](https://graphql.org/blog/2025-09-04-multioption-inputs-with-oneof/). [RFC #825](https://github.com/graphql/graphql-spec/pull/825) - **Schema Coordinates** \ A standardized way to refer to parts of a schema, paving the way for better tooling, error reporting, and developer experience. [RFC #794](https://github.com/graphql/graphql-spec/pull/794) - **Descriptions on Documents** \ Improved support for documenting queries and operations — helpful for humans and increasingly relevant for AI-powered tools. [RFC #1170](https://github.com/graphql/graphql-spec/pull/1170) - **Expanded Deprecation Support** \ Deprecation is now more broadly supported across schema elements, making it easier to evolve APIs without breaking clients. \[RFCs [#805](https://github.com/graphql/graphql-spec/pull/805), [#1040](https://github.com/graphql/graphql-spec/pull/1040), [#1053](https://github.com/graphql/graphql-spec/pull/1053), [#1142](https://github.com/graphql/graphql-spec/pull/1142)\] - **Full Unicode Support** \ The language grammar now supports the entire Unicode range, improving internationalization and accessibility. [RFC #849](https://github.com/graphql/graphql-spec/pull/849) - **Editorial Improvements** \ The spec is clearer, more consistent, and easier to contribute to. Ambiguities have been reduced, and the style guide has been modernized. ## **Thank you, contributors!** This edition wouldn’t exist without the dedication of the GraphQL community. Dozens of contributors — from core maintainers to first-time spec authors — invested their time and expertise to make GraphQL better for everyone. Special thanks to the many reviewers, implementers, and champions who shaped this release. You can explore the full list of contributors in the [changelog](https://github.com/graphql/graphql-spec/blob/main/changelogs/September2025.md). ## **Get involved** GraphQL is a living standard. If you’re building APIs, tooling, or clients, your voice matters in shaping its future. Anyone can join [working group meetings](https://github.com/graphql/graphql-wg) and contribute proposals, reviews, or feedback. 📖 **Read the full spec:** [GraphQL September 2025 Specification](https://spec.graphql.org/September2025/) \ 🔎 **Review all changes:** [Full changelog & diff](https://github.com/graphql/graphql-spec/compare/October2021...f29fbcd2ab5af763fce7ad62896eb62465a669b3) \ 🤝 **Contribute:** [How to get involved](https://github.com/graphql/graphql-spec/blob/main/CONTRIBUTING.md) --- --- title: "🚀 What Launched at GraphQLConf 2025" tags: ["blog"] date: 2025-10-20 byline: Jeff Auriemma and An Ngo featured: true --- _Article 1 of 4 GraphQLConf 2025 posts_ GraphQLConf 2025 was a launchpad for new tooling and infrastructure by GraphQL vendors, indie maintainers, and enterprise-backed open source organizations. Read on to learn more about what's now available for GraphQL users! ## 📋 The Latest GraphQL Specification ![Speaker Photo](https://live.staticflickr.com/65535/54774915705_11d1dd94e6_c.jpg)

[Lee Byron - GraphQL Specification September 2025 Edition](https://graphql.org/conf/2025/schedule/fe829e6aab214193a809c31e4b0c832a/?name=Keynote:%20Opening%20Remarks%20-%20Lee%20Byron,%20Co-Creator%20of%20GraphQL%20&%20Director,%20GraphQL%20Foundation)

The program kicked off with the announcement of the September 2025 edition of the GraphQL Specification by Lee Byron in his opening keynote. Read more about what's new in GraphQL here. --- ## 📦 New Data Fetching Concepts

[Michael Staib - Offset Pagination Is Dead! Meet Relative Cursors](https://graphql.org/conf/2025/schedule/73b37145c961856b3c857568d0739a9f/?name=Lightning%20Talk:%20Offset%20Pagination%20Is%20Dead!%20Meet%20Relative%20Cursors%20-%20Michael%20Staib,%20ChilliCream)

Michael Staib introduced relative cursors so teams can keep familiar jump to page flows while gaining the reliability and efficiency of cursor based pagination. ---

[Matt Mahoney - @async: Defer Even More!](https://graphql.org/conf/2025/schedule/4614b0dbd6236e202a87270ceda0c3bf/?name=@async:%20Defer%20Even%20More!%20-%20Matt%20Mahoney,%20Meta)

Matt Mahoney unveiled Meta's @async directive so products request data only when needed, trimming the hidden costs that @defer can leave behind. ---

[Raymie Stata - Rethinking GraphQL Execution](https://graphql.org/conf/2025/schedule/9426f470312d5ebb39a99a3a822f2821/?name=Rethinking%20GraphQL%20Execution%20-%20Raymie%20Stata,%20Airbnb)

Raymie Stata detailed Airbnb's newly open-sourced Viaduct framework, with separate resolution and completion phases, a planner that orchestrates them, and shared data structures that keep one thousand contributors efficient. --- ## 🚀 GraphQL Application Development ![Martin Bonnin](https://live.staticflickr.com/65535/54774799549_1423365e40_c.jpg)

[Martin Bonnin - Compose Your Mobile App With GraphQL](https://graphql.org/conf/2025/schedule/33ba3777057f6b5d6e17b0e6fe86e7d9/?name=Compose%20Your%20Mobile%20App%20With%20GraphQL%20-%20Martin%20Bonnin,%20Apollo)

Martin Bonnin demonstrated a new library for Apollo Kotlin users to work with colocated fragments in their Jetpack Compose apps. ---

[Robert Balicki - GraphQL in a World of Full-stack, Rich Clients: The Next Evolution](https://graphql.org/conf/2025/schedule/a2bb7f46355a46dcab47d654c9ccbe4e/?name=GraphQL%20in%20a%20World%20of%20Full-stack,%20Rich%20Clients:%20The%20Next%20Evolution%20-%20Robert%20Balicki,%20Pinterest)

Robert Balicki won the Academy Award for most theatrical talk showcasing the latest innovations in the Isograph framework. ---

[Benoit Lubek - Next-Generation GraphQL Cache Management in Your Android and iOS Apps](https://graphql.org/conf/2025/schedule/a0e2a06e7fa0578e1b252beef517aef2/?name=Lightning%20Talk:%20Next-Generation%20GraphQL%20Cache%20Management%20in%20Your%20Android%20and%20iOS%20Apps%20-%20Benoit%20Lubek,%20Apollo%20GraphQL)

Benoit Lubek shared the latest Apollo Kotlin and iOS cache upgrades, covering pagination, expiration, and offline first patterns for mobile teams. ---

[Lenz Weber-Tronic - Reintroducing Apollo Client: V4 and Beyond](https://graphql.org/conf/2025/schedule/efe5aee612551209ba413d57d3ddbb4e/?name=Reintroducing%20Apollo%20Client:%20V4%20and%20Beyond%20-%20Lenz%20Weber-Tronic,%20Apollo%20GraphQL)

Lenz Weber-Tronic unpacked the latest modernizations and features shipped in Apollo Client with query preloading, suspense, fragment APIs, and masking that keep complex apps fast and maintainable. ---

[Alec Aivazis - GraphQL Isn't Just for Enterprises: The New King of Fullstack Typescript Applications](https://graphql.org/conf/2025/schedule/dda1fbb70f8b5b73223a6e37a736e5bd/?name=GraphQL%20Isn%27t%20Just%20for%20Enterprises:%20The%20New%20King%20of%20Fullstack%20Typescript%20Applications%20-%20Alec%20Aivazis,%20HoudiniLabs)

Alec Aivazis showed the Houdini developer experience, demonstrating how smaller teams can sprint from idea to production with GraphQL first tooling. ---

[Jason Kuhrt - Hello Graffle! A Modular Type Safe GraphQL Client](https://graphql.org/conf/2025/schedule/ce3c04db5c598ba5451fcd71df4849ee/?name=Lightning%20Talk:%20Hello%20Graffle!%20A%20Modular%20Type%20Safe%20GraphQL%20Client%20-%20Jason%20Kuhrt,%20The%20Guild)

Jason Kuhrt showed off the Graffle library (formerly graphql-request), unveiling a plugin-first approach that combines a document builder, OTEL support, and in-memory execution for TypeScript apps. --- ## 🔌 Protocol Innovations

[Tom Houle - The Federated GraphQL Subscriptions Zoo](https://graphql.org/conf/2025/schedule/f4c4515cba67a0ef57bb208e2c805c6c/?name=Lightning%20Talk:%20The%20Federated%20GraphQL%20Subscriptions%20Zoo%20-%20Tom%20Houlé,%20Grafbase)

Tom Houle mapped the protocol translations required to keep subscriptions alive across federated gateways, from SSE to WebSocket bridges to payload handshakes. ---

[Matteo Collina - GraphQL Subscriptions Are Stateful; We Made Them Stateless](https://graphql.org/conf/2025/schedule/0c3828d450fca7c409a3dda68f066428/?name=GraphQL%20Subscriptions%20Are%20Stateful;%20We%20Made%20Them%20Stateless%20-%20Matteo%20Collina,%20Platformatic)

Matteo Collina shared Platformatic's approach to resumable subscriptions that protect real time updates from WebSocket disconnects. --- ## 🤝 GraphQL Federation ![Dotan Simha & Kamil Kisiela](https://live.staticflickr.com/65535/54774915925_68fdf4e61a_c.jpg)

[Dotan Simha & Kamil Kisiela - Building an Open-Source Federation Query Planner & Router](https://graphql.org/conf/2025/schedule/1a0475a575803503fce927f22dd1beae/?name=Building%20an%20Open-Source%20Federation%20Query%20Planner%20&%20Router%20-%20Dotan%20Simha%20&%20Kamil%20Kisiela,%20The%20Guild)

Dotan Simha and Kamil Kisiela introduced The Guild's Rust based router, sharing benchmarks, modular query planner design, and ways the community can plug in. ---

[Samuel Bernardo Vazquez Andalon - Building a Kotlin Federated GraphQL Gateway and Executor](https://graphql.org/conf/2025/schedule/cb0e7d61d4055d199e7b9040617c2f88/?name=Building%20a%20Kotlin%20Federated%20GraphQL%20Gateway%20and%20Executor%20-%20Samuel%20Bernardo%20Vázquez%20Andalón,%20Expedia%20Group)

Samuel Bernardo Vazquez Andalon highlighted Expedia Group's Kotlin router, leaning on DSLs to configure distributed GraphQL deployments. ---

[Benjamin Rabier & Tom Houle - Beyond GraphQL Federation: How We Use Composite Schemas and WebAssembly to Federate Non-GraphQL Data Sources](https://graphql.org/conf/2025/schedule/3712b5f88962e155f080a7afa612e46e/?name=Workshop:%20Beyond%20GraphQL%20Federation:%20How%20We%20Use%20Composite%20Schemas%20and%20WebAssembly%20to%20Federate%20Non-GraphQL%20Data%20Sources%20-%20Benjamin%20Rabier%20&%20Tom%20Houlé,%20Grafbase)

Benjamin Rabier and Tom Houle guided attendees through combining Apollo Federation V2, composite schemas, and WebAssembly so any backend can join the graph. ---

[Denis Badurina & Arda Tanrikulu - Unleash the Power of Federation with Hive Gateway](https://graphql.org/conf/2025/schedule/6fbc71a3ad13189339d753cb078ec781/?name=Workshop:%20Unleash%20the%20Power%20of%20Federation%20with%20Hive%20Gateway%20-%20Denis%20Badurina%20&%20Arda%20Tanrıkulu,%20The%20Guild)

Denis Badurina and Arda Tanrikulu walked teams through Hive Gateway's OpenTelemetry support, automatic batching, JWT authentication, rate limiting, and subscriptions. ---

[Michael Staib - Composite Schemas in Action](https://graphql.org/conf/2025/schedule/3b8701f24da2cf5456ffd5b793836ace/?name=Workshop:%20Composite%20Schemas%20in%20Action%20-%20Michael%20Staib,%20Chillicream)

Michael Staib offered a hands on look at the Composite Schema Specification and how it standardizes multi service graphs. ---

[Benjamin Rabier - Deep Dive Into a GraphQL Federation Gateway, From Query Planning To the Execution](https://graphql.org/conf/2025/schedule/d017baa3d96bc8ee7e195dbdce137a96/?name=Deep%20Dive%20Into%20a%20GraphQL%20Federation%20Gateway,%20From%20Query%20Planning%20To%20the%20Execution%20-%20Benjamin%20Rabier,%20Grafbase)

Benjamin Rabier explained Grafbase's Steiner tree query planner and lock free execution DAG that keep responses low latency. ---

[Tom Houle - Authorization in Federated GraphQL](https://graphql.org/conf/2025/schedule/4c9e99eb72e65a8115cabc6df964e106/?name=Lightning%20Talk:%20Authorization%20in%20Federated%20GraphQL%20-%20Tom%20Houlé,%20Grafbase)

Tom Houle showcased federation aware directives and policies in Grafbase Gateway that let platform teams centralize authorization without blocking subgraph autonomy. --- ## 🛠️ Tooling & DX ![Fiona Huang](https://live.staticflickr.com/65535/54777774072_34df1566e3_k.jpg)

[Fiona Huang - One API Definition To Rule Them All: Generating GraphQL Schemas From TypeSpec](https://graphql.org/conf/2025/schedule/0843f99870a32c08d091379a43d0c224/?name=One%20API%20Definition%20To%20Rule%20Them%20All:%20Generating%20GraphQL%20Schemas%20From%20TypeSpec%20-%20Fiona%20Huang,%20Pinterest)

Fiona Huang announced Pinterest's TypeSpec GraphQL emitter that collapses REST and GraphQL definitions into a single source. ---

[Mark Larah - Hacking the Federation Query Planner](https://graphql.org/conf/2025/schedule/806eaa5ecdc05b0c0f01165c7980b4a6/?name=Hacking%20the%20Federation%20Query%20Planner%20-%20Mark%20Larah,%20Yelp)

Mark Larah unpacked a difficult concurrency edge case Yelp encountered and the long term spec fixes emerging through Composite Schemas. ---

[Vanessa Johnson - What If GraphQL Knew Accessibility?](https://graphql.org/conf/2025/schedule/87264d07e7aaafb1811ba5ad451285a2/?name=Lightning%20Talk:%20What%20If%20GraphQL%20Knew%20Accessibility?%20-%20Vanessa%20Johnson,%20The%20New%20York%20Times)

Vanessa Johnson proposed embedding accessibility metadata directly in schemas so tooling can generate inclusive experiences by default. ---

[Jordan Eldredge - Grats: Bringing Implementation-First GraphQL to TypeScript](https://graphql.org/conf/2025/schedule/e9075771b5513faaf06cca527e7a837d/?name=Grats:%20Bringing%20Implementation-First%20GraphQL%20to%20TypeScript%20-%20Jordan%20Eldredge,%20Meta)

Jordan Eldredge previewed Meta's static analysis pipeline, showing how developers can build GraphQL servers in TypeScript without giving up type safety. ---

[Eddy Nguyen - Building the Ideal GraphQL Server Workflow Featuring GraphQL Code Generator](https://graphql.org/conf/2025/schedule/0281a72e8e35f07c74a5815c42c64a02/?name=Sponsored%20Session:%20Building%20the%20Ideal%20GraphQL%20Server%20Workflow%20Featuring%20GraphQL%20Code%20Generator%20-%20Eddy%20Nguyen,%20SEEK%20&%20The%20Guild)

Eddy Nguyen walked through a refreshed workflow powered by GraphQL Code Generator, highlighting stronger typing, fewer runtime errors, and lessons from a decade of community effort. ---

[Derek Kuc - Efficient Semantic Comparison of GraphQL Queries](https://graphql.org/conf/2025/schedule/deac4044512d6d0a59c76aa712a777a4/?name=Lightning%20Talk:%20Efficient%20Semantic%20Comparison%20of%20GraphQL%20Queries%20-%20Derek%20Kuc,%20Apollo%20GraphQL)

Derek Kuc unveiled static analysis that proves when two queries are equivalent and makes refactoring safer. --- ## 🙏 Thank You, Attendees and Sponsors! GraphQLConf 2025 was held in September 2025 in Amsterdam and attended by over 250 GraphQL enthusiasts. The GraphQL Foundation would like to thank our sponsors: **Gold Sponsors** - [Apollo GraphQL](https://www.apollographql.com/) - [The Guild](https://the-guild.dev/graphql/hive) **Silver Sponsors** - [Grafbase](https://grafbase.com/) - [Meta](https://about.facebook.com/meta/) - [Netflix](https://netflix.com/) ## Blogposts & Upcoming GraphQL events Stay tuned, this is a serie of articles on GraphQLConf 2025. More articles will be published soon! For upcoming events and GraphQL Local initiatives, please visit our [GraphQL community events](https://graphql.org/community/events/) page. --- --- title: "GraphQL: A data query language" tags: ["blog", "spec", frontend, backend] date: 2015-09-14 byline: "Lee Byron" --- When we built Facebook's mobile applications, we needed a data-fetching API powerful enough to describe all of Facebook, yet simple and easy to learn so product developers can focus on building things quickly. We developed GraphQL three years ago to fill this need. Today it powers hundreds of billions of API calls a day. This year we've begun the process of open-sourcing GraphQL by drafting a specification, releasing a reference implementation, and forming a community around it here at [graphql.org](/). ## Why GraphQL? Back in 2012, we began an effort to rebuild Facebook's native mobile applications. At the time, our iOS and Android apps were thin wrappers around views of our mobile website. While this brought us close to a platonic ideal of the "write one, run anywhere" mobile application, in practice it pushed our mobile-webview apps beyond their limits. As Facebook's mobile apps became more complex, they suffered poor performance and frequently crashed. As we transitioned to natively implemented models and views, we found ourselves for the first time needing an API data version of News Feed — which up until that point had only been delivered as HTML. We evaluated our options for delivering News Feed data to our mobile apps, including RESTful server resources and FQL tables (Facebook's SQL-like API). We were frustrated with the differences between the data we wanted to use in our apps and the server queries they required. We don't think of data in terms of resource URLs, secondary keys, or join tables; we think about it in terms of a graph of objects and the models we ultimately use in our apps like NSObjects or JSON. There was also a considerable amount of code to write on both the server to prepare the data and on the client to parse it. This frustration inspired a few of us to start the project that ultimately became GraphQL. GraphQL was our opportunity to rethink mobile app data-fetching from the perspective of product designers and developers. It moved the focus of development to the client apps, where designers and developers spend their time and attention. ## What is GraphQL? A GraphQL query is a string that is sent to a server to be interpreted and fulfilled, which then returns JSON back to the client. ```graphql # { "graphiql": true, "schema": "Users" } { user(id: 4802170) { id name isViewerFriend profilePicture(size: 50) { uri width height } friendConnection(first: 5) { totalCount friends { id name } } } } ``` **Defines a data shape:** The first thing you'll notice is that GraphQL queries mirror their response. This makes it easy to predict the shape of the data returned from a query, as well as to write a query if you know the data your app needs. More important, this makes GraphQL really easy to learn and use. GraphQL is unapologetically driven by the data requirements of products and of the designers and developers who build them. **Hierarchical:** Another important aspect of GraphQL is its hierarchical nature. GraphQL naturally follows relationships between objects, where a RESTful service may require multiple round-trips (resource-intensive on mobile networks) or a complex join statement in SQL. This data hierarchy pairs well with graph-structured data stores and ultimately with the hierarchical user interfaces it's used within. **Strongly typed:** Each level of a GraphQL query corresponds to a particular type, and each type describes a set of available fields. Similar to SQL, this allows GraphQL to provide descriptive error messages before executing a query. It also plays well with the strongly typed native environments of Obj-C and Java. **Protocol, not storage:** Each GraphQL field on the server is backed by a function - code linking to your application layer. While we were building GraphQL to support News Feed, we already had a sophisticated feed ranking and storage model, along with existing databases and business logic. GraphQL had to leverage all this existing work to be useful, and so does not dictate or provide any backing storage. Instead, GraphQL takes advantage of your existing code by exposing your application layer, not your storage layer. **Introspective:** A GraphQL server can be queried for the types it supports. This creates a powerful platform for tools and client software to build atop this information like code generation in statically typed languages, our application framework, Relay, or IDEs like GraphiQL (pictured below). GraphiQL helps developers learn and explore an API quickly without grepping the codebase or wrangling with cURL. ```graphql # { "graphiql": true, "schema": "Users" } { __type(name: "User") { name fields { name type { name } } } } ``` **Version free:** The shape of the returned data is determined entirely by the client's query, so servers become simpler and easy to generalize. When you're adding new product features, additional fields can be added to the server, leaving existing clients unaffected. When you're sunsetting older features, the corresponding server fields can be deprecated but continue to function. This gradual, backward-compatible process removes the need for an incrementing version number. We still support three years of released Facebook applications on a single version of our GraphQL API. With GraphQL, we were able to build full-featured native News Feed on iOS in 2012, and on Android shortly after. Since then, GraphQL has become the primary way we build our mobile apps and the servers that power them. More than three years later, GraphQL powers almost all data-fetching in our mobile applications, serving millions of requests per second from nearly 1,000 shipped application versions. When we built GraphQL in 2012 we had no idea how important it would become to how we build things at Facebook and didn't anticipate its value beyond Facebook. However, earlier this year we announced Relay, our application framework for the web and React Native built atop GraphQL. The community excitement for Relay inspired us to revisit GraphQL to evaluate every detail, make improvements, fix inconsistencies, and write a specification describing GraphQL and how it works. Two months ago, we [made our progress public](https://youtube.com/watch?v=WQLzZf34FJ8) and released a working draft of the [GraphQL spec](https://spec.graphql.org) and a reference implementation: [GraphQL.js](https://github.com/graphql/graphql-js). Since then, a community has started to form around GraphQL, and versions of the GraphQL runtime are being [built in many languages](https://github.com/chentsulin/awesome-graphql), including Go, Ruby, Scala, Java, .Net, and Python. We've also begun to share some of the tools we use internally, like [GraphiQL](https://github.com/graphql/graphiql), an in-browser IDE, documentation browser, and query runner. GraphQL has also seen production usage outside Facebook, in a project for the [_Financial Times_](https://youtube.com/watch?v=S0s935RKKB4) by consultancy [Red Badger](http://red-badger.com). “GraphQL makes orchestrating data fetching so much simpler, and it pretty much functions as a perfect isolation point between the front end and the back end” — Viktor Charypar, software engineer at Red Badger While GraphQL is an established part of building products at Facebook, its use beyond Facebook is just beginning. Try out [GraphiQL](http://graphql-swapi.parseapp.com/graphiql) and help provide feedback on our [specification](https://github.com/facebook/graphql). We think GraphQL can greatly simplify data needs for both client product developers and server-side engineers, regardless of what languages you're using in either environment, and we're excited to continue to improve GraphQL, help a community grow around it, and see what we can build together. --- --- title: "Subscriptions in GraphQL and Relay" tags: ["blog", "spec", "frontend"] date: 2015-10-16 byline: Dan Schafer and Laney Kuenzel --- When we announced and open-sourced GraphQL and Relay this year, we described how they can be used to perform reads with queries, and to perform writes with mutations. However, oftentimes clients want to get pushed updates from the server when data they care about changes. To support that, we’ve introduced a third operation into the GraphQL specification: subscription. ## Event-based subscriptions The approach that we’ve taken to subscriptions parallels that of mutations; just as the list of mutations that the server supports describes all of the actions that a client can take, the list of subscriptions that the server supports describes all of the events that it can subscribe to. Just as a client can tell the server what data to refetch after it performs a mutation with a GraphQL selection, the client can tell the server what data it wants to be pushed with the subscription with a GraphQL selection. For example, in the Facebook schema, we have a mutation field named `storyLike`, that clients can use to like a post. The client might want to refetch the like count, as well as the like sentence (“Dan and 3 others like this”. We do this translation on the server because of the complexity of that translation in various languages). To do so, they would issue the following mutation: ```graphql mutation StoryLikeMutation($input: StoryLikeInput) { storyLike(input: $input) { story { likers { count } likeSentence { text } } } } ``` But when you’re looking at a post, you also want to get pushed an update whenever someone else likes the post! That’s where subscriptions come in; the Facebook schema has a subscription field named `storyLikeSubscribe` that allows the client to get pushed data anytime someone likes or unlikes that story! The client would create a subscription like this: ```graphql subscription StoryLikeSubscription($input: StoryLikeSubscribeInput) { storyLikeSubscribe(input: $input) { story { likers { count } likeSentence { text } } } } ``` The client would then send this subscription to the server, along with the value for the `$input` variable, which would contain information like the story ID to which we are subscribing: ```graphql input StoryLikeSubscribeInput { storyId: string clientSubscriptionId: string } ``` At Facebook, we send this query to the server at build time to generate a unique ID for it, then subscribe to a special MQTT topic with the subscription ID in it, but many different subscription mechanisms could be used here. On the server, we then trigger this subscription every time someone likes a post. If all of our clients were using GraphQL, we could put this hook in the GraphQL mutation; since we have non-GraphQL clients as well, we put the hook in a layer below the GraphQL mutation to ensure it always fires. ## Why not Live Queries? Notably, this approach requires the client to subscribe to events that it cares about. Another approach is to have the client subscribe to a query, and ask for updates every time the result of that query changes. Why didn’t we take that approach? Let’s look back at the data we wanted to refetch for the story: ```graphql fragment StoryLikeData on Story { story { likers { count } likeSentence { text } } } ``` What events could trigger that a change to the data fetched in that fragment? - Someone likes the post. - Someone unlikes the post. - Someone who had liked the post deactivates their account (changes the like count down one, changes the like sentence to decrement the translated count). - Someone who had liked the post reactivates their account (changes the like count up one, changes the like sentence to increment the translated count). - Someone who had liked the post blocks you (cannot show them in the like sentence). - Someone who had liked the post changes their name (need to update the text of the like sentence). - Our internal ranking model for the ordering of names in the like sentence updates, and we should be listing a different person first (want to update the text of the like sentence). And that’s just the tip of the iceberg in terms of events; each of those events also becomes tricky when there are thousands of people subscribed, and millions of people who liked the post. Implementing live queries for this set of data proved to be immensely complicated. When building event-based subscriptions, the problem of determining what should trigger an event is easy, since the event defines that explicitly. It also proved fairly straight-forward to implement atop existing message queue systems. For live queries, though, this appeared much harder. The value of our fields is determined by the result of their resolve function, and figuring out all of the things that could alter the result of that function was difficult. We could in theory have polled on the server to implement this, but that had efficiency and timeliness issues. Based on this, we decided to invest in the event-based subscription approach. ## What’s next? We’re actively building out the event-based subscription approach described above. We’ve built out live liking and commenting features on our iOS and Android apps using that approach, and are continuing to flesh out its functionality and API. While its current implementation at Facebook is coupled to Facebook’s infrastructure, we’re certainly looking forward to open sourcing our progress here as soon as we can. Because our backend and schema don’t offer easy support for live queries, we don’t have any plans to develop them at Facebook. At the same time, it’s clear that there are backends and schemas for which live queries are feasible, and that they offer a lot of value in those situations. The discussion in the community on this topic has been fantastic, and we’re excited to see what kind of live query proposals emerge from it! Subscriptions create a ton of possibilities for creating truly dynamic applications. We’re excited to continue developing GraphQL and Relay with the help of the community to enable these possibilities. --- --- title: "Mocking your server is easy with GraphQL" date: 2016-04-19 tags: ["blog", "frontend"] byline: "Jonas Helfer" guestBio: engineer at Meteor working on Apollo --- Do you think mocking your backend is always a tedious task? If you do, reading this post might change your mind… Mocking is the practice of creating a fake version of a component, so that you can develop and test other parts of your application independently. Mocking your backend is a great way to quickly build a prototype of your frontend, and it lets you test your frontend without starting up any servers. API mocking is so useful that a [quick Google search](https://www.google.com/?ion=1&espv=2#q=mock+rest+api) will turn up dozens of expensive products and services that promise to help you. Sadly, I think none of the solutions out there make it as easy as it should be. As it turns out, that’s because they’ve been trying to do it with the wrong technology! > Editor’s note : The concepts in this post are accurate, but some the code samples don’t demonstrate new usage patterns. After reading, consult the [graphql-tools docs](http://dev.apollodata.com/tools/graphql-tools/mocking.html) to see how to use mocking today. ## Why mock? Mocking the data a backend would return is very useful for two main reasons: 1. It lets you start developing a frontend feature when you don’t have a working backend for it yet. This is critical for projects where the frontend and backend components are often developed in parallel. 2. It lets you run tests locally without connecting to a real backend, which is much faster and safer. As your codebase grows and your app becomes more complex, starting up all of the server infrastructure just to run some tests isn’t feasible. If mocking your backend API has such clear benefits, why doesn’t everyone do it? I think it's because mocking often seems like too much trouble to be worth it. ## Why is mocking backends hard? Let’s say your backend is some REST API that is called over HTTP from the browser. You have someone working on the backend, and someone else working on the frontend. The backend code actually determines the shape of the data returned for each REST endpoint, but mocking has to be done in the frontend code. That means the mocking code will break every time the backend changes, unless both are changed at the same time. What’s worse, if you’re doing your frontend testing against a mock backend that is not up to date with your backend, your tests may pass, but your actual frontend won’t work. Rather than having to keep more dependencies up to date, the easy option is to just not mock the REST API, or have the backend be in charge of mocking itself, just so it’s all in one place. That may be easier, but it will also slow you down. The other reason I often hear for why people don’t mock the backend in their project is because it takes time to set up: first you have to include extra logic in your data fetching layer that lets you turn mocking on and off, and second you have to actually describe what that mock data should look like. For any non-trivial API that requires a lot of tedious work. Both of these reasons for why mocking backends is hard are actually due to the same underlying reason: there is no standard REST API description in machine-consumable format and contains all the information necessary for mocking and can be used by both the backend and the frontend. There are some API description standards, like Swagger, but they don’t contain all of the information you need, and can be cumbersome to write and maintain. Unless you want to pay for a service or a product — and maybe even then — mocking is a lot of work. Actually, I should say mocking used to be a lot of work, because a new technology is changing the way we think of APIs: GraphQL. ## Mocking is easy with a type system! GraphQL makes mocking easy, because every GraphQL backend comes with a static type system. The types can be shared between your backend and your frontend, and they contain all of the information necessary to make mocking incredibly fast and convenient. With GraphQL, there is no excuse to not mock your backend for development or testing. Here’s how easy it is to create a mocked backend that will accept any valid GraphQL query with the GraphQL mocking tool we are building as part of our new [GraphQL server toolkit](https://github.com/apollostack/graphql-tools): ```js // > npm install graphql-tools import { mockServer } from "graphql-tools" import schema from "./mySchema.graphql" const myMockServer = mockServer(schema) myMockServer.query(`{ allUsers: { id name } }`) // returns // { // data: { // allUsers:[ // { id: 'ee5ae76d-9b91-4270-a007-fad2054e2e75', name: 'lorem ipsum' }, // { id: 'ca5c182b-99a8-4391-b4b4-4a20bd7cb13a', name: 'quis ut' } // ] // } // } ``` Every GraphQL server needs a schema, so it’s not extra code you need to write just for mocking. And the query is the one your component already uses for fetching data, so that’s also not code you write just for mocking. Not counting the import statement, it only took us one line of code to mock the entire backend! Put that in contrast to most REST APIs out there, where mocking means parsing a URL and returning data in a custom shape for each endpoint. It takes dozens of lines to mock a single endpoint that returns some realistic-looking data. With GraphQL, the shape is encoded in the query, and together with the schema we have enough information to mock the server with a single line of code. Did I mention that this one line is all you need to return mock data for any valid GraphQL query you could send? Not just some valid query, any valid query! Pretty cool, right? ## Customizing mock data In the example above, the mock server will return completely random IDs and strings every time you query it. When you’ve just started building your app and only want to see what your UI code looks like in different states, that’s probably good enough, but as you start to fine-tune your layout, or want to use the mock server to test your component’s logic, you’ll probably need more realistic data. Luckily, this takes only a little more effort: customization of mock data is really where the Apollo mocking tool shines, because it lets you customize virtually everything about the mock data that it returns. It lets you do all of the following and more: ```js // customize mocking per type (i.e. Integer, Float, String) mockServer(schema, { Int: () => 6, Float: () => 22.1, String: () => 'Hello' }) // customize mocking per field in the schema (i.e. for Person.name and Person.age) mockServer(schema, { Person: () => ({ name: casual.name, age: () => casual.integer(0,120) }) }) // mock lists of specific or random length( and lists of lists of lists …) mockServer(schema, { Person: () => ({ // a list of length between 2 and 6 friends: () => new MockList([2,6]), // a list of three lists of two items: [[1, 1], [2, 2], [3, 3]] listOfLists: () => new MockList(3, () => new MockList(2)) }) }) // customize mocking of a field or type based on the query arguments mockServer(schema, { Person: () => ({ // the number of friends in the list now depends on numPages paginatedFriends: (o, { numPages }) => new MockList(numPages * PAGE_SIZE) }) }) // You can also disable mocking for specific fields, pass through to the backend, etc. ``` For each type and each field you can provide a function that will be called on to generate mock data. Mock functions on fields have precedence over mock functions on types, but they work together really nicely: The field mock functions only need to describe the properties of the objects that matter to them, type mock functions will fill in the rest. The mock functions are actually just GraphQL resolve functions in disguise. What that means is that your mocking can do anything that you could do inside a GraphQL resolve function. If you wanted, you could write your entire backend with it. I’m not saying you should, but you could. I think the real power of this tool is that while it allows almost arbitrarily complex customization, you can get started really quickly and increase the sophistication of your mocks in tiny steps whenever you need it. Each step is so simple that it will feel like a breeze. But enough talking, here’s a complete example: ```js import { mockServer, MockList } from "graphql-tools" import casual from "casual-browserify" // The GraphQL schema. Described in more detail here: // https://medium.com/apollo-stack/the-apollo-server-bc68762e93b const schema = ` type User { id: ID! name: String lists: [List] } type List { id: ID! name: String owner: User incomplete_count: Int tasks(completed: Boolean): [Task] } type Task { id: ID! text: String completed: Boolean list: List } type RootQuery { user(id: ID): User } schema { query: RootQuery } ` // Mock functions are defined per type and return an // object with some or all of the fields of that type. // If a field on the object is a function, that function // will be used to resolve the field if the query requests it. const server = mockServer(schema, { RootQuery: () => ({ user: (o, { id }) => ({ id }), }), List: () => ({ name: () => casual.word, tasks: () => new MockList(4, (o, { completed }) => ({ completed })), }), Task: () => ({ text: casual.words(10) }), User: () => ({ name: casual.name }), }) mockServer.query(` query tasksForUser{ user(id: 6) { id name lists { name completeTasks: tasks(completed: true) { completed text } incompleteTasks: tasks(completed: false) { completed text } anyTasks: tasks { completed text } } } }`) ``` ## Live demo + try it yourself To see the example in action and see what output it generates, head over to the [live demo](https://launchpad.graphql.com/98lq7vz8r) try running some queries! If you want to fiddle around with the example, just click the "Download" button in the Launchpad UI. If you’re curious about how it works or want to see what other tools we’re building for GraphQL, then head over to [apollostack/graphql-tools](https://github.com/apollostack/graphql-tools). Pretty cool, right? All of that becomes possible by using a type system. And that’s only just the beginning — we‘re working on bridging the gap between mocking and the real thing so that your mock server can gradually turn into your real server as you add more functionality to it. --- _This post was originally published on [the Apollo Blog](https://medium.com/apollo-stack). We publish one or two posts every week, about the stuff we’re working on and thinking about._ --- --- title: "Wrapping a REST API in GraphQL" tags: ["blog"] date: 2016-05-05 byline: "Steven Luscher" --- Time and time again I hear the same aspiration from front-end web and mobile developers: they're eager to reap the developer efficiency gains offered by new technologies like Relay and GraphQL, but they have years of momentum behind their existing REST API. Without data that clearly demonstrates the benefits of switching, they find it hard to justify an additional investment in GraphQL infrastructure. In this post I will outline a rapid, low-investment method that you can use to stand up a GraphQL endpoint atop an existing REST API, using JavaScript alone. No backend developers will be harmed during the making of this blog post. ## A client-side REST wrapper We're going to create a _GraphQL schema_ – a type system that describes your universe of data – that wraps calls to your existing REST API. This schema will receive and resolve GraphQL queries all on the client side. This architecture features some inherent performance flaws, but is fast to implement and requires no server changes. Imagine a REST API that exposes a `/people/` endpoint through which you can browse `Person` models and their associated friends. ![A REST API that exposes an index of people][rest-api-people] We will build a GraphQL schema that models people and their attributes (like `first_name` and `email`) as well as their association to other people through friendships. ### Installation First we'll need a set of schema building tools. ```sh npm2yarn npm i graphql ``` ### Building the GraphQL Schema Ultimately we will want to export a `GraphQLSchema` that we can use to resolve queries. ```js import { GraphQLSchema } from "graphql" export default new GraphQLSchema({ query: QueryType, }) ``` At the root of all GraphQL schemas is a type called `query` whose definition we provide, and have specified here as `QueryType`. Let's build `QueryType` now – a type on which we will define all the possible things one might want to fetch. To replicate all of the functionality of our REST API, let's expose two fields on `QueryType`: - an `allPeople` field – analogous to `/people/` - a `person(id: String)` field – analogous to `/people/{ID}/` Each field will consist of a return type, optional argument definitions, and a JavaScript method that resolves the data being queried for. ```js import { GraphQLList, GraphQLObjectType, GraphQLString, } from 'graphql'; const QueryType = new GraphQLObjectType({ name: 'Query', description: 'The root of all... queries', fields: () => ({ allPeople: { type: new GraphQLList(PersonType), resolve: root => {} // Fetch the index of people from the REST API, }, person: { type: PersonType, args: { id: { type: GraphQLString }, }, resolve: (root, args) => {} // Fetch the person with ID `args.id`, }, }), }); ``` Let's leave the resolvers as a sketch for now, and move on to defining `PersonType`. ```js import { GraphQLList, GraphQLObjectType, GraphQLString, } from 'graphql'; const PersonType = new GraphQLObjectType({ name: 'Person', description: 'Somebody that you used to know', fields: () => ({ firstName: { type: GraphQLString, resolve: person => person.first_name, }, lastName: { type: GraphQLString, resolve: person => person.last_name, }, email: {type: GraphQLString}, id: {type: GraphQLString}, username: {type: GraphQLString}, friends: { type: new GraphQLList(PersonType), resolve: person => {} // Fetch the friends with the URLs `person.friends`, }, }), }); ``` Note two things about the definition of `PersonType`. Firstly, we have not supplied a resolver for `email`, `id`, or `username`. The default resolver simply accesses the property of the `person` object that has the same name as the field. This works everywhere except where the property names do not match the field name (eg. the field `firstName` does not match the `first_name` property of the response object from the REST API) or where accessing the property would not yield the object that we want (eg. we want a list of person objects for the `friends` field, not a list of URLs). Now, let's write resolvers that fetch people from the REST API. Because we need to load from the network, we won't be able to return a value right away. Luckily for us, `resolve()` can return either a value or a `Promise` for a value. We're going to take advantage of this to fire off an HTTP request to the REST API that eventually resolves to a JavaScript object that conforms to `PersonType`. And here we have it – a complete first-pass at the schema: ```js {28,38,45} import { GraphQLList, GraphQLObjectType, GraphQLSchema, GraphQLString, } from 'graphql'; const BASE_URL = 'https://myapp.com/'; function fetchResponseByURL(relativeURL) { return fetch(`${BASE_URL}${relativeURL}`).then(res => res.json()); } function fetchPeople() { return fetchResponseByURL('/people/').then(json => json.people); } function fetchPersonByURL(relativeURL) { return fetchResponseByURL(relativeURL).then(json => json.person); } const PersonType = new GraphQLObjectType({ /* ... */ fields: () => ({ /* ... */ friends: { type: new GraphQLList(PersonType), resolve: person => person.friends.map(fetchPersonByURL), }, }), }); const QueryType = new GraphQLObjectType({ /* ... */ fields: () => ({ allPeople: { type: new GraphQLList(PersonType), resolve: fetchPeople, }, person: { type: PersonType, args: { id: { type: GraphQLString }, }, resolve: (root, args) => fetchPersonByURL(`/people/${args.id}/`), }, }), }); export default new GraphQLSchema({ query: QueryType, }); ``` ### Using a client-side schema with Relay Normally, Relay will send its GraphQL queries to a server over HTTP. We can inject [@taion](https://github.com/taion/)'s custom `relay-local-schema` network layer to resolve queries using the schema we just built. Put this code wherever it's guaranteed to be executed before you mount your Relay app. ```sh npm2yarn npm i relay-local-schema ``` ```js import RelayLocalSchema from 'relay-local-schema'; import schema from './schema'; Relay.injectNetworkLayer( new RelayLocalSchema.NetworkLayer({ schema }) ); ``` And that's that. Relay will send all of its queries to your custom client-resident schema, which will in turn resolve them by making calls to your existing REST API. ## A server-side REST wrapper The client-side REST API wrapper demonstrated above should help you get up and running quickly so that you can try out a Relay version of your app (or part of your app). However, as we mentioned before, this architecture features some inherent performance flaws because of how GraphQL is still calling your underlying REST API which can be very network intensive. A good next step is to move the schema from the client side to the server side to minimize latency on the network and to give you more power to cache responses. Take the next 10 minutes to watch me build a server side version of the GraphQL wrapper above using Node and Express.