September 2026 edition: https://graphql.org/blog/2026-11-13-september-2026-graphql-spec/

Initial release of the GraphQL over HTTP spec: https://graphql.org/blog/2026-11-12-announcing-the-graphql-over-http-spec/

Happy reading!

Hey all,

I used graphql-modules for a while and loved it. But I kept hitting bugs in how it handles context during execution, and Apollo Server support has been an open PR since 2023 (#2444). So I built my own take on it. It's called olio, and I'd like people to poke holes in it.

Same idea: modules merged into one schema. The difference is ownership. graphql-modules lets two modules declare the same field and both resolve it, and whichever module is listed last silently wins. In olio a field belongs to exactly one module.

import { module } from "@nxara/olio";
import { loaders } from "@nxara/olio-tools";

const load = loaders(import.meta.dirname);

export const usersModule = module.users({
  typeDefs: await load.typeDefs("typedefs/*.gql"),
  resolvers: {
    Query: { user: (_root, { id }) => findUser(id) },
  },
});

With codegen, id is typed from the SDL, and a posts module resolving User.name is a compile error. olio checks the same rule at runtime. app.schema is a plain GraphQLSchema, so you can run it on Yoga, Apollo Server, graphql-http or anything else.

Also:

• Modules extend type Query with no placeholder, so a module can be tested on its own

• Layered middleware (app, module, feature), with @bypass in the SDL for fields that should skip it

• @excl for login-style fields that need the operation to themselves, so other fields can't run with a stale session

• Schema errors with file:line:column

Only @nxara/olio is required. Codegen, an HTTP server, a typed client and DI are optional.

It's early (0.1.x). I'd love to hear:

• If you're on graphql-modules, what keeps you there and what hurts?

• Is the ownership rule useful, or too strict?

• Does anything in the API look weird?

Docs: https://olio.nxara.dev Repo: https://github.com/nxara-hub/olio

The docs site has an llms.txt and an agent skill.

I'm Stephen, and I built RockxyBit, a native macOS API client.

I wanted GraphQL requests to live in the same workspace as the rest of my API work, rather than in a separate tool. In RockxyBit, a GraphQL request sits beside your REST requests in the same collection, uses the same environments, and gives you the same response inspection.

What is in the 0.1.0 release:
- Collections and environments, so the same request can run against local, staging, and production
- Response inspection for headers, body, and timing
- Import from cURL, HAR, Postman, OpenAPI, and SoapUI, so an existing collection does not have to be rebuilt by hand
- Secrets stored in the macOS Keychain rather than in plain project files
- A native macOS interface, signed and notarized

It requires macOS 26.2 or later.

Website: https://rockxy.io/rockxybit
Bug report and feature request: https://github.com/RockxyApp/RockxyBit

I would value feedback from people who work with GraphQL APIs every day, particularly on how the request and response flow feels compared with the tools you use now. BTW, just try it and appreciate your feedback!

Hey r/graphql,

I've been working on a desktop GraphQL client called GraphQLab, and I'd love some honest feedback from people who live in GraphQL tooling every day.

Why I built it

I wanted something between GraphiQL and the big API platforms: a fast, focused client that doesn't require an account, doesn't sync my queries and tokens to someone's cloud, and doesn't fight CORS.

What it does

• Projects & environments: each project has multiple environments (endpoint + default headers + reusable {{variables}}), so switching between local / staging / prod is one click.

• Schema-aware editor: CodeMirror 6 with live introspection: autocomplete, validation and hover docs.

• No CORS headaches: requests run in the Electron main process, so you can hit any endpoint.

• File uploads: full graphql-multipart-request-spec support through the native file picker.

• Per-request variables & headers, plus a searchable run history per project.

• Local-first: everything lives in a local SQLite database. No cloud, no sign-up.

• Dark/light themes, keyboard-first (⌘/Ctrl + Enter to run).

Stack: Electron + React + TypeScript + Vite, zustand, better-sqlite3. MIT licensed.

Links: https://graphqlab.com

What I'd like to know

• What's the one feature that would make you switch from your current client?

• How do you handle auth flows (OAuth, rotating tokens) in your day-to-day? That's something I'm thinking about next.

• Anything about the schema explorer / docs UX that annoys you in other tools?

It's still early (v0.1.x), so bug reports and blunt opinions are very welcome. Thanks for reading!

🇬🇧 Graphql Generator that generate REST client? are we going back?

Well sometimes we need to go back to see the bigger picture.

Find out why we added the generation of RESTful client from an advanced graphql code generator.

🇫🇷 Un générateur GraphQL qui génère des clients REST ? On fait marche arrière ?

Eh bien, parfois il faut prendre du recul pour voir la vue d'ensemble.

Découvrez pourquoi nous avons ajouté la génération de clients RESTful à un générateur de code GraphQL avancé.

Hi r/graphql, I'm Kay, the founder of GraphPilot. (Disclosure: this is my product.)

I spent years on the GraphQL orchestration layer of a large streaming platform, working with the federated teams that built on it. I wasn't happy with the edge caching options for GraphQL, and their developer experience didn't fit teams like ours. A classic CDN doesn't get you far either: most traffic is POST, one endpoint serves every query, and a TTL either serves old data or expires far too often.

The part that took the longest was invalidation. If a page only asked for title and price, the cached answer contains no id and no ISBN, so a purge for "book 9780441013593" has nothing to match, and the safe fallback is to flush everything.

How GraphPilot handles it:

• It sits in front of your existing GraphQL API, on Fastly's edge network, and caches responses at the edge (POST, GET and persisted queries).

• It reads your schema. If a selection doesn't ask for the key fields, the edge adds them to the request it sends to your origin (the id, plus your own keys marked with @surrogateKey, like an ISBN), tags the cached response with them, and strips them again before the client sees it.

• When a mutation goes through GraphPilot, the cached responses that contained the returned objects are purged at every edge location, usually within seconds. For data that changes elsewhere, there's a purge API and a CLI (e.g. from a CMS webhook), a Surrogate-Key header from your origin, or the Cockpit UI.

• Per-user or per-role data is split into separate cache entries based on verified JWT claims.

• The Cockpit shows hit rate, latency and every purge with the keys it cleared, and for each miss, why it wasn't cached.

Limits, honestly: a new item only shows up in a cached list if that list carries a key the create names; changes that bypass GraphPilot need an API or CLI purge; WebSocket connections are passed through, not cached.

The video above is the full 8-minute explainer. Links to the free plan and the docs are in the first comment.

I'd love feedback on the invalidation model, and on how you cache GraphQL today. Critical questions are very welcome.

I'm the author of GraphLink, a schema-first code generator for typed GraphQL clients (Dart, Java, Kotlin, TypeScript, Swift), so take this with that in mind.

GraphQL lets the client pick its fields, but a lot of client code still has one model per schema type, and anything you didn't select becomes nullable or missing. For a query that selects id, title and year from Book, GraphLink generates a class with only those three fields, so non-null fields in the schema stay non-null in the client.

I know other generators do something similar for operations. I'd like to hear what works for you, and where this breaks down.

Video (Dart): https://youtu.be/gHGtCBYaj7c

Write-up: https://medium.com/@graphlinkdev/custom-graphql-queries-in-dart-select-only-the-fields-you-need-8a9cf12887f5

Twelve items this week:

Community

• GraphQL Stars 2026 and the new People of GraphQL page — the Foundation recognising maintainers, contributors, educators and organisers

Tools & open source

• Hive Router supports Federation contexts (@context / @fromContext) — nested fields get data from ancestors without a public argument; all distinct context values resolved in one subgraph request (Denis Badurina)

• GraphQL Yoga v6 — adopts Hive Logger (structured per-request logging), supports the latest @defer / @stream spec, drops EOL Node and GraphQL < 16 (Emily Goodwin)

• hive_router anonymize — replaces every name and value in a supergraph and its operations with keyed hashes so you can share them in a bug report without revealing your schema (Kamil Kisiela)

Events

• Apollo Summit 2026 Recap: What's New in GraphOS for Agents and Apps (online)

• GraphQL Lucknow Meetup — Oct 31

• GraphQL Noida Meetup — Oct 31

• London GraphQL, Winter edition — Nov 24

Articles

• When GraphQL earns its place in an enterprise application, and when it doesn't (InfoWorld, Vaishnavi Khosla) — where it saves time, where it adds complexity, when REST is the better fit

Videos

• GraphQL MCP Code Mode at Expedia (Samuel Vazquez) — an 18,000-type supergraph collapsed to two agent tools, search and execute; 14x fewer tool calls, 82% less context

• How I explain GraphQL to strangers (Jeff Auriemma) — the food-ordering analogy

• We Built a Context Graph at RS Group (Juan Carlos Blanco Delgado) — a four-person team's agents tracing issues across schema, pipelines, tickets and monitoring

Disclosure: I curate GraphQL Weekly and work at The Guild — Hive Router and Yoga are ours. Happy to answer questions on any of it.

GraphQL Yoga v6 shipped yesterday, led by Emily Goodwin with Denis Badurina and Arda Tanrikulu helping. The short version:

• Structured, per-request logging via Hive Logger (context.log, auto-correlated request IDs that respect your host framework’s ID, e.g. Fastify’s request.id)

• Support for the latest incremental delivery (@defer/u/stream) spec: request it with Accept: multipart/mixed;incrementalSpec=v0.2, legacy clients keep working

• Node 22+ and GraphQL 16+ only; u/graphql-tools/* bumped to current majors, some re-exports removed

Migration guide: https://the-guild.dev/graphql/hive/product-updates/2026-10-24-yoga-adopts-hive-logger-support-latest-defer-steam-spec-drops-legacy-node-and-graphql

And there’s a lot more in store now that v6 is out of the way.

I’m one of the founders of The Guild, so take this with that in mind, but I wanted to share some history because I think it explains why Yoga ended up where it is.

2021: Envelop. Back then the GraphQL server landscape was stuck. Most servers were in maintenance mode (or worse), u/defer/u/stream and u/oneOf were out of reach, and performance was far behind what’s possible. Dotan built Envelop as a plugin system on top of the GraphQL engine rather than yet another server: hook into parse/validate/context/execute, and share caching, tracing, auth, persisted operations etc. as plugins that work with any HTTP server and any schema builder. https://the-guild.dev/graphql/hive/blog/introducing-envelop

2022: Yoga v2. Prisma handed Yoga over to us. Rather than maintain the old codebase we rewrote it from scratch on Envelop and the WHATWG Fetch API. That decision is why the same Yoga code runs on Node, Cloudflare Workers, Lambda, Deno, Bun and Next.js, why it’s been spec-compliant (GraphQL-over-HTTP, multipart) from day one, and why we run perf checks on every commit. https://the-guild.dev/graphql/hive/blog/announcing-graphql-yoga-v2

2026. More than five years later the project has new people leading releases and the bet on Envelop + Fetch keeps paying off. Yoga is the default server for many frameworks, the engine under Hive Gateway and GraphQL Mesh, there’s a first-class NestJS driver, and it’s the subgraph server in a lot of federated setups. The reason, I think, is that it doesn’t lock you in: bring your own schema library, HTTP framework and runtime, and extend with plugins.

My general advice when picking open source infrastructure: ask whether it will still be maintained in five years, not just whether it works today.

Happy to answer questions about v6, the migration, or the history. And if you have requests for Yoga, Emily is actively looking for them: comment here or open an issue.

https://github.com/KLR-Pattern/fastapi-mcp-neo

GraphQL's original pitch — one round trip, ask for exactly the fields you need — was designed for constrained clients. LLM agents are that client again, with a twist: every byte of every tool response lands in the context window, and context is the budget.

I built fastapi-mcp-neo (Python, MIT). Point it at an existing FastAPI app and it derives a GraphQL schema with zero decorators and zero model changes:

• tags → domain groups (notes { mine { get_note } })

• endpoint function names → field names

• Pydantic models / TypedDicts / dataclasses → GraphQL types

• docstrings and Field(description=...) → schema descriptions

Then it serves that schema to AI agents over MCP as a constant 2–6 tools (get_schema, graphql_query, graphql_mutation, plus progressive-disclosure discovery) instead of one tool per endpoint.

Humans get the same schema: GraphiQL and POST /graphql come along free.

Why bother — measured on a 100-route app against the mainstream OpenAPI→tools bridge (FastMCP.from_openapi):

• tool catalog: ~1,500–2,500 tokens constant vs ~15,400 growing linearly (agents re-read the catalog every session)

• two-endpoint task: 1 graphql_query round trip vs 2 tool calls / 2 agent turns

• field projection: same list response 2,285 B whole-payload vs 610 B for { id title }

• single-call latency: statistically tied (1.39 vs 1.41 ms p50) — the win is turns and tokens, not ms

How Monday.com scaled for AI by redesigning their API edge to handle 2.5x more traffic with 92% less CPU

Twelve items this week, heavy on Apollo Summit announcements:

Articles

• MCP gets AI agents into your APIs (The New Stack, Matt DeBergalis) — field-level control over what an agent can read and do, without a separate tool per team

• Apollo Summit 2026 product highlights (Kaitlyn Barnard) — GraphOS Agent Services, GraphOS Desktop, GraphOS Factory, Connectors v0.4

• Introducing GraphOS Agent Services (Adam DeLisse) — governed, auditable agent access to enterprise systems; public preview

• How Apollo knows a Router performance result is real (Dan Anderson Hall) — the Runtime Testing Framework behind each release

Tools & open source

• GraphOS Router Support Tool (Danielle Mallare) — one-pass support archive with automatic redaction, stays inside your infra

• Baton (Valentin Shergin) — Relay for SwiftUI and Compose: a fragment beside every view, one request per screen

• Apollo Connectors v0.4 is GA (Ben Newman) — REST/HTTP APIs into GraphQL with no resolver code

• Apollo Rover 1.0 is GA (Brian George) — OAuth login, profiles, schema checks

• GraphiQL v6 coming soon (Trevor Scheer) — full reskin plus a query builder and operation collections; try the preview

• Welcoming AI contributions to GraphQL Codegen and Inspector (Eddy Nguyen) — maintainer-written skills that make AI PRs follow the same steps a good contributor would; 6x more merged PRs last month

Events

• GraphQL Day @ FOST Melbourne, Oct 29

Videos

• Sharon Gorla (Lead Engineer, Starbucks) with Jeff Auriemma on building durable architectures and domain models

Disclosure: I curate GraphQL Weekly and work at The Guild — Codegen and Inspector are Guild projects. Happy to answer questions on any of it.

Hey all,

I've been maintaining and working on GraphiQL and its next major version for the better part of this year. Among some other improvements, it's been fully reskinned and comes with a couple new first-party plugins: a query builder and operation collections.

It's currently in `rc` and I'm hoping to see some people actually using it before I cut to `latest`, so please try it out if you're able. Feedback and issues are welcome. I'm fairly responsive on GitHub and the GraphQL Discord server.

Here's the draft migration guide so far, and if you're using an LLM you can probably just point it there and tell it to complete the upgrade for you.

Here's a screenshot I have handy just to give an idea of the reskin and a preview of the query builder plugin:

I benchmarked Apollo, Mercurius and Yoga on Express, Fastify and plain node:http, with and without NestJS: 10 setups, same schema and queries, load-tested with k6. It's a follow-up to my earlier NestJS GraphQL benchmark, where the most common question was how much NestJS itself costs.

Results (M1 Max, Node 24, single process, 50 VUs, median of 3 runs):

- The GraphQL engine matters most: Mercurius did 1.3–1.8× the req/s of Apollo in every query scenario. On the deep nested query: 902 vs 493 req/s, p99 68 ms vs 123 ms. Yoga landed in between on real queries
- The HTTP framework matters mostly for tiny queries: with Apollo, Fastify beat Express by 18–29% on a tiny query, but only ~3% on the deep nested one.
- NestJS vs the same stack without it: −6% to +5%, and the sign flips between scenarios. That's within run-to-run noise.
- Mutations: every server did ~9–9.4k req/s.

Both sides use the same library versions (NestJS 10.4 with Fastify 4.28, Express 4.22, Apollo Server 4.13, Mercurius 14.1, Yoga 5.10). In-memory data, no DB, so the ratios matter more than the absolute numbers.

Code, raw results and the dashboard: https://github.com/vovadyach/gql-bench

Hey folks. Shameless plug.

I built a GraphQL client for SwiftUI and Jetpack Compose. I honestly think it is kind of amazing, and it might be useful to some of you. Give me a minute.

It is called Baton: https://github.com/shergin/baton

One line: Relay for native mobile. Not a client that borrows a few Relay ideas. The compiler is built on Relay's own front end.

Fragments are checked against the schema when the app builds. The directives are the ones you already know: @connection, @refetchable, @argumentDefinitions, @required, @catch, @defer, @appendEdge, @deleteRecord. Persisted operations go through persistConfig. If the web team runs Relay, the mobile team now uses the same words.

The fragment sits on the view that draws it. It is a real GraphQL document, in the Swift file:

struct IssueRow: View {
    @Fragment("""
    fragment IssueRow_issue on Issue {
      number
      title
      author { login }
    }
    """)
    var issue: IssueRow_issue

    var body: some View {
        Text("#\(issue.number) \(issue.title)")
    }
}

Kotlin is the same shape. An annotation sits on the composable. The screen has one query. That query spreads the fragments, and the compiler puts them together. There is no view model, no mapper, and no .graphql file in another folder. A row can read only the fields its fragment declared.

Why these two frameworks, and why this is not a port of the React runtime

Relay's runtime exists to answer one question: which view read which field? When data changes, only those views update.

SwiftUI and Compose already answer that question. SwiftUI has Observation. Compose has snapshot state. So Baton keeps Relay's compiler and the write side of the store, and drops the read side. It does not port that read side.

What gets dropped is the React machinery: snapshots, re-reads, selectors, and suspending by throwing a promise. React needs those. GraphQL does not.

The store is the UI's state. Each record is an object the UI can watch. Each field is a tracked property in Swift, or snapshot state in Kotlin.

A fragment compiles to a lens. A lens is a typed, read-only view of one record, with one accessor for each field the fragment declared. The response is not decoded into a model and handed to a view. A parent passes a reference to the record.

Masking is not a rule the runtime enforces. It is the shape of the type. If the fragment did not declare a field, the lens has no accessor for it.

A mutation arrives and a title changes. The Text that read that title updates. The row next to it does not. Masking, connections, optimistic responses, subscriptions, and @defer all follow from that one idea.

Why it is fast

I tried hard to design for speed from the first day, and it shows:

• Every operation is fixed at build time. The compiler emits a normalization plan for each operation, and the runtime runs that plan. At run time it does not parse GraphQL, look up a cache policy, or hash a field name. Each storage key is a constant the compiler emits, numbered once per process.

• Ingest turns response bytes straight into record slots, off the main thread. There is no model in between. There is no JSON tree, no Codable, no dictionaries, and no Any on the read path.

• The commit is one atomic batch on the main thread. It writes the slots that changed, and it notifies the fields that views on screen actually read. An unchanged refetch of a 900-record page costs the main thread under 200 µs, and nothing re-renders.

• Reads are synchronous. A handle reads the store before the view's body runs the first time, so cached data is on screen in the first frame.

• The on-disk copy is a SQLite image, written behind the UI and loaded before the first body. A cold start draws from disk.

• Generated code is one line per field, plus data tables. The runtime depends on Foundation, Observation, and the SQLite that ships with the system. No third-party code is bundled in.

The numbers in my own app are great, but your mileage may vary. If you try it, tell me what yours are.

It works with any server that follows the spec, including Apollo Server and Apollo Router. It asks for nothing beyond the spec.

If you have a GraphQL backend and a native app, try it on one screen. Then tell me what would stop you from shipping it. 🙇‍♂️

Eight items this week:

Tools & open source

• Apollo Client 4.3 by Jerel Miller — native custom scalar support, type-safe cache access, more consistent @defer / @stream

• GraphOS Router 3.0 by Matthew Ratzke — faster query planning, more deployment control, native circuit breaking; in Preview

• Hive Gateway can now compose the subgraphs running on your machine via a new dev supergraph source, locally or alongside the rest of your graph through the Hive registry (Jeff Dolle)

• Apollo Mock by Martin Bonnin — LLM-generated mock data for Kotlin apps

Events

• GraphQL Day @ FOST Melbourne, Oct 29

Articles

• How Comcast scaled analytics 80x while cutting costs 38% with GraphQL and Amazon S3 Tables — AWS customer story; also 28% lower query latency (Bimal Gajjar et al.)

Videos

• Martin Bonnin (Apollo Kotlin maintainer, GraphQL TSC) with Jeff Auriemma on GraphQL governance and what GraphQL needs right now

• Samuel Vazquez (Principal Engineer, Expedia) on AI mocks and semantic search with Jev for GraphQL

Disclosure: I curate GraphQL Weekly and work at The Guild, so the Hive Gateway item is ours. Happy to answer questions on any of it.

I’m building a learning project with Express, TypeScript, MongoDB, and graphql-http. Everything runs through Docker Compose.

I’m adding query-abuse protection, starting with depth validation before resolvers execute. I tried @graphile/depth-limit, but its peer dependency excludes my GraphQL version.

Relevant versions:

graphql: 17.0.2
graphql-http: 1.23.1
/depth-limit: 0.3.1 (attempted installation)

Command:

docker compose exec backend npm install /depth-limit

Error:

npm error code ERESOLVE
npm error ERESOLVE unable to resolve dependency tree

npm error Found: [email protected]
npm error node_modules/graphql
npm error   graphql@"^17.0.2" from the root project

npm error Could not resolve dependency:
npm error peer graphql@">=15 <17" from /[email protected]

The package’s dependency declaration confirms graphql: ">=15 <17".

My intended integration is a validation rule passed to the existing HTTP handler:

const handler = createHandler({
  schema,
  rootValue,
  validationRules: [depthRule],
  context: createRequestContext,
});

I’d prefer to keep GraphQL 17 and avoid --force or --legacy-peer-deps without evidence of compatibility.

What are people using for depth limits with graphql-js 17?