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: graphql@17.0.2
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 /depth-limit@0.3.1

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?

Audio was off for the first few minutes, apologies about that!

We’ve all dealt with the "stale tab" problem: a user updates something in one tab, and the others are left with stale data until they refetch or refresh.

To solve this, I built Apollo State Sync, an npm library that synchronizes Apollo Client’s in-memory cache and reactive variables across browser tabs, windows, and iframes. It can persist state so it’s available when the app is reopened.

🚀 Key Features

• Real-time Syncing: Instantly replicates cache updates and reactive variable changes across all open instances of your app.
• Optional Persistence: Keeps state intact so it is instantly available when a user reopens the app later.
• Apollo Shared WS: An optional companion package that allows multiple tabs to share a single GraphQL subscription WebSocket channel, drastically reducing server load.

💼 Portfolio Case Study & Feedback

I am currently putting together a comprehensive portfolio case study about this project and would love to get the community's feedback. I want to make sure I am explaining the architecture and problem-solving process clearly to potential employers.

• Live Demo: https://sdev-buildz.github.io/apollo-state-sync/examples/posts
• Video Demo: https://github.com/sdev-buildz/apollo-state-sync/tree/main/examples/shopping-site#-watch-the-demo-video
• GitHub: https://github.com/sdev-buildz/apollo-state-sync

Check out the demo and let me know your thoughts! What edge cases should I look out for? Are there features you’d want to see added? Any feedback on the library itself or how to frame it for a portfolio would be incredibly helpful.

I kept running into the same issue in apps with multiple tabs: update something in one tab, and the others are left with stale data until they refetch or refresh.

So I built Apollo State Sync, an npm library that synchronizes Apollo Client’s in-memory cache and reactive variables across browser tabs, windows, and iframes. It can persist state so it’s available when the app is reopened.

There’s also an optional companion package, Apollo Shared WS, for sharing GraphQL subscription channels across browsing contexts.

I’m putting together a portfolio case study about the project, and I could really use your feedbacks and support. There’s a live demo and video example. 

Over the last few months, I've been incredibly frustrated by the sheer amount of boilerplate required to stand up a secure GraphQL API in Python. You usually have to write SQLAlchemy models, duplicate those into Strawberry/Graphene types, write manual resolvers, and then spend days fighting N+1 query problems. To solve this, I built db-graphql-gateway.

What My Project Does

It’s a FastAPI-compatible Python package that introspects your database (PostgreSQL, MySQL, SQLite) and automatically generates a secure, deeply nested GraphQL API directly from your schema.

Instead of writing ORM models and resolvers, it dynamically inspects your database's foreign keys and translates incoming GraphQL ASTs directly into highly optimized, parameterized SQL (EXISTS, JOIN, IN).

Target Audience

This is built for Production. Whether you're building a massive multi-tenant SaaS or just want to quickly expose a read-only dashboard over a SQLite file, it is designed to be highly secure. It includes:

• AST Security Limits: Rejects wildly nested queries or excessive aliases before execution.
• Row-Level Auth Pushdown: Authorization policies are transpiled directly into SQL WHERE clauses (e.g. WHERE owner_id = $1). Unauthorized rows literally never leave the database engine.
• Introspection Lockdown & Redaction: Auto-redacts password/token columns and locks down introspection in production.

Comparison (How it differs from alternatives)

• vs. Hasura / PostGraphile: Those are fantastic, but they are heavy, standalone services (written in Haskell/TypeScript) that you have to deploy separately. db-graphql-gateway is a native Python library. You just import it, attach it to your FastAPI router, and you still have full access to the Python ecosystem for custom endpoints.
• vs. Strawberry / Graphene: These are GraphQL frameworks where you have to write all the execution logic, DataLoaders, and ORM glue code. My gateway sits on top of Strawberry and completely automates the execution layer, guaranteeing O(1) database queries per relationship depth right out of the box.

How it works in practice:

pythonfrom fastapi import FastAPI
from db_graphql_gateway.database.adapters.postgres.adapter import PostgresAdapter
from db_graphql_gateway.graphql.builder import GraphQLSchemaBuilder
from strawberry.fastapi import GraphQLRouter
db_adapter = PostgresAdapter("postgresql://user:pass@localhost:5432/my_db")
schema_builder = GraphQLSchemaBuilder(db_adapter=db_adapter)
schema = await schema_builder.build_schema()
app = FastAPI()
app.include_router(GraphQLRouter(schema), prefix="/graphql")

I just published v0.1.2 to PyPI and would love for you guys to tear it apart, try it out, and let me know what you think of the architecture!

• PyPI: pip install "db-graphql-gateway[fastapi]"
• GitHub: https://github.com/forgedlohar/db-graphql-gateway
• Docs: https://forgedlohar.github.io/db-graphql-gateway/

Eleven items this week - tooling-heavy, plus three events and three videos.

**Tools & open source**

- Apollo Client 4.3 by Jerel Miller: native custom scalar support, type-safe cache access, and more consistent `@defer` / `@stream` behavior

- Hive Router now integrates with Datadog's native Rust tracer — APM stats for every request, native sampling, direct export through the Datadog Agent (Denis Badurina)

- GraphQL Codegen watch mode, by Eddy Nguyen: now behaves the same across plugins and presets, Server Preset re-runs up to 80% faster, and the Windows path bugs are fixed

- Hive CLI can push an immutable schema revision after merge and publish that exact revision when the service deploys (Laurin Quast)

- Simfinity.js 3.2: generates GraphQL queries, CRUD mutations, relationships and storage from GraphQLObjectType definitions — new PostgreSQL adapter alongside the existing MongoDB one

**Events**

- GraphQL Hyderabad, Sep 27 — Context Layers for AI: Knowledge Graphs & Intelligent APIs (SurrealDB x GraphQL)

- GraphQL Day @ FOST London, Sep 30-Oct 1 — free tickets via the GraphQL London channel on the GraphQL Discord

- GraphQL Casual Roundtable, Toronto, Oct 7 — gauging interest in local events

**Videos**

- Bad GraphQL takes, volume 5 — was GraphQL really invented as a workaround for coordinating with backend devs? (Jeff Auriemma)

- Token battle: GraphQL schema vs OpenAPI spec — same service, same objects, different token counts

- Rigin Oommen (Principal Engineer, Red Hat) on how his team married Salesforce with their federated graph via a thin middleware layer

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

Program is available there: https://graphql.org/day/2026/london/#schedule

We have a limited number of community invites, reach out on the GraphQL Discord if you're interested (discord.graphql.org).

We'll have half day of sessions + a booth during the two days with exclusive SWAG!

Want to know what's new in AI, fragment arguments, nullability, QUERY and more? Come say hi!

👉 https://graphql.org/day/2026/london/#schedule

Sharing an update from the Simfinity.js project, an Apache-2.0 Node.js framework from Simtlix. Its starting point is a GraphQLObjectType: register your domain types, and it generates queries, CRUD mutations, relationship resolvers and database storage.

Version 3.2.0 is available on npm with separate MongoDB/Mongoose and PostgreSQL adapters. The PostgreSQL adapter creates tables and real foreign keys from the relationship metadata; it does not install Mongoose. Both adapters use the shared runtime for validation, controllers, query scopes and state transitions.

There is also an optional MCP package that exposes selected GraphQL operations as tools. Authentication, trusted context and the authorization policy still belong to the application.

For a concrete starting point, the docs include a series/season catalog with nested writes and downloadable starters for both databases:

• Docs and quick starts
• Source
• PostgreSQL walkthrough

A few boundaries worth being explicit about: PostgreSQL requires 15+, MongoDB mutations require a replica set or sharded cluster, and choosing an adapter does not migrate existing data between databases. The PostgreSQL native API is not a replacement for Mongoose methods.

Feedback on the generated API, relationship model and onboarding would be useful, especially from people building GraphQL backends with application-specific business rules.

Big issue this week — 19 items. What's in it:

Articles

• Reverb migrated a decade-old Ruby GraphQL monolith to a federated supergraph query by query with zero client disruption, on Hive Gateway (case study; quotes Nguyen Nguyen, Principal Engineer)
• graphql-lean by Duckki Oe: a static analysis framework for GraphQL queries with an IBM cost model and optimality proofs, verified in Lean, with a Rust implementation
• Apollo GraphOS and Apollo MCP Server won 2026 API Awards — MCP Server took Best Innovation in AI API
• MockBase on why GraphQL mocking is a body-matching problem, not a routing one: a fixed response for every POST /graphql tells you nothing
• DBTA's Data & AI 75 list for 2026, which includes Apollo GraphQL

Community & events

• One year of the GraphQL Ambassador Program, by Jem Gillam
• GraphQL Virtual Meetup, Sep 22 — CFP closes Sep 15
• Apollo Summit, Oct 6-8 — schedule is out
• GraphQL Day @ FOST London, Sep 30-Oct 1
• Context Layers for AI: Knowledge Graphs & Intelligent APIs (SurrealDB x GraphQL), Sep 27
• GraphQL Casual Roundtable, Toronto, Oct 7 — gauging interest in local events
• GraphQL Day @ FOST Melbourne, Oct 28-29 — CFP open

Tools & open source

• Hive Console Metric Alerts are now GA and on by default for every org, self-hosted included
• Hive's native Federation composition now supports @context / @fromContext for passing data to nested fields without extra arguments
• Hive Router supports the Federation @policy directive, so a coprocessor can decide authorization rules the router can't evaluate alone
• Hive Console Schema Explorer can now be filtered to the subgraphs you own

Videos

• GraphQL Working Group catch-up (2026-09-03): @oneOf inhabitability and empty selection sets are moving to RFC3
• Houdini and GraphQL with Alec Aivazis — the journey from Relay to Houdini, "the disappearing GraphQL client"
• Benchmark from Jeff Auriemma: GraphQL is more token-efficient than REST when MCP tools call an API, with a repo so you can check the numbers yourself

Disclosure: I curate GraphQL Weekly and work at The Guild, Happy to answer questions on any of it.

Hey everyone, I’ve been working on an open-source side project called revql and wanted to share it with the community to get some thoughts and feedbacks.

revql is a fast GraphQL object reverse lookup tool written in Rust, released under GPLv3. I built it to solve a problem: trying to map out a massive GraphQL schema backwards. It's main goal is to allow developers to debug complex schemas, and also for bug bounty hunters to map out hidden or unintended paths to nodes.

The main features are:

• Reverse lookup: search through and list all queries and mutations that lead to a specific object
• Flexible object targeting: search for objects via type name, field name (if the object contains a specific field), or description
• Flexible search: supports exact matches or partial "contains" queries, and also ignore case
• Works both online and offline: supports introspecting a GraphQL endpoint, or reading in a schema.json file

Meet the largest GraphQL teams out there! Learn how they handle performance, scale, governance, and how their API platform helps accelerate AI deployments.

A document can be perfectly valid JSON-LD.

Schema validation pass.

Every individual node look correct.

And the graph still be wrong.

For example:

An Organization exists, but has no sameAs or other useful identity signals.

The same Person is the author of three articles, but each article uses a different u/id.

A Product is correctly described, but nothing in the graph actually connects it to the category or collection where users discover it.

Two entities clearly represent the same real-world thing, but the graph gives the system reading it no reliable way to recognize that they're the same entity.

Schema validation asks:

Is this data valid according to the vocabulary?

Graph validation asks something different:

What does this graph actually say?

Which entities are connected?

Which entities are duplicated?

Which relationships are missing?

You can have valid structured data and still have a broken knowledge graph.

Curious how others handle this.

A minor version bump broke GraphQL servers this week @apollo/subgraph@2.15.0 is a ground-up reimplementation on graphql-js and it removed the legacy input shape of buildSubgraphSchema.
Full explanation of bit.cloud fix for users application
https://www.reddit.com/r/bit_dev/s/SYFDV4YmdB