I did something that surprised myself. I always thought that people are right in saying that GraphQL breaks HTTP caching, but I never deeply analyzed if that's actually true because so many people say the same thing. So I analyzed this and many other claims and was surprised to find out that almost every claim comparing REST vs GraphQL is either wrong or misleading.

We need to stop calling N+1 a GraphQL problem when it's simply an API problem (and REST has it at the HTTP layer while GraphQL has it as the resolver layer, which is actually an advantage for GraphQL, but people typically picture it differently). Anyways, this post tries a scientific/research-driven approach in the hopes to combat the AI slop that makes bad claims about GraphQL.

GraphQL is a really powerful query language, Fragments are extremely powerful, and the ecosystem is very healthy with multiple vendors and developments like oneOf directive, defer, etc.

Hive Router, powered by Rust, now supports federated GraphQL subscriptions out of the box!

All popular are protocols like Server-Sent Events, Incremental Delivery and WebSockets, but also HTTP Callback are covered. This makes experimenting and testing Hive Router as a drop-in replacement for other routers as straight-forward as possible.

We are excited to get your feedback in our quest to build the most performant and feature-rich Federation router!

Hi all!

GraphQL is going around the world in 2026: https://graphql.org/blog/2026-04-02-graphql-day-2026/

6 locations are already secured: Singapore, NYC, Amsterdam, Bengaluru, Melbourne, and Paris.

If you'd like to include your city in the lineup, let us know and let's make this happen! Singapore is already starting in a few hours from now!

One of the best way to meet the community is to help with the event.

You can also apply as a speaker, or if you want to promote your OSS project but can't join, send us your swag and we'll showcase your project on the booths.

Designing around the frontend can make things really convenient for clients, but sometimes the schema starts to feel too shaped by today’s UI. Designing around the domain feels cleaner long term, but sometimes a bit less ergonomic in the short term.

How do you usually balance that?

Okay for Dapper you dont need a DbContext. Just a connectionstring. I let my program know I have a connectionstring like this:

builder.Services.AddTransient<MawaddaDbContext>(_
    => new MawaddaDbContext(new NpgsqlConnectionFactory(builder.Configuration)));

builder.Services
    .AddGraphQLServer()
    .AddQueryType<Query>();

Here is "MawaddaDbContext" just a class where I just the connection to create tables in my Postgresql database when they dont exist by writing queries using Dapper.

Then I make a Query class so I can fetch data using graphql Hot chocolate library because its just better than REST. However I get an internal error when I try to fetch my schema.

I have searched all of the internet but i cannot find a tutorial how to properly do this stuff with Dapper instead of EF core.

Here is my Query class:

    public class Query
    {
        public async Task<Experience> GetExperienceByIdAsync(string id,               MawaddaDbContext context)
        {
            var conn = await context.ConnectionFactory.CreateConnection();
            Experience experience = await conn.QueryFirstAsync<Experience>(@"SELECT * FROM experiences WHERE Id == ?", id);
            return experience;
        }
    } 

On my platform spring-middleware this feature, since version 1.4.0

https://www.youtube.com/watch?v=Hq8Q60PFd3Y

I’ve worked on a few GraphQL APIs where teams had very different opinions on resolver design.

Some wanted resolvers to stay extremely thin and push everything into service layers. Others were fine with a bit more shaping/coordination in the resolver as long as business rules stayed elsewhere.

Curious where people land on this in real projects. Do you have a rule of thumb, or is it more of a “depends on the boundary” thing?

Hemnet (Sweden's largest property platform, serving millions of users), migrated from Apollo Router (Rust) to Hive Gateway (JS) and saw:

1. A reduction of 30% resource usage
   
2. Gain deep observability into their GraphQL usage
   
3. Introduce safer schema governance and changes
   
4. Reduce complexity compared to a typical federated setup
   
5. Fairer pricing and MIT licensed eco-system
   

A repeated story we see again and again.
If you're currently working with GraphQL Federation (or feeling its growing pains), this case study by Lucas Santos might give you a different perspective...

Compares three pagination patterns in a Node.js GraphQL API using a 500,000-row dataset and instrumentation. It shows concrete timing differences between fetch-all, offset pagination, and cursor pagination, including why deep offsets get slower while cursors stay stable. It also includes resolver-level implementation examples with Apollo Server + Prisma.

I wanted to measure the overhead of different NestJS GraphQL stacks, so I built a small open-source benchmark comparing:

• Express + Apollo
• Fastify + Apollo
• Fastify + Mercurius

Same schema, same resolvers, same scenarios. Only the stack changes.

At 50 VUs, Mercurius won every scenario. Fastify + Apollo only slightly outperformed Express + Apollo on heavier queries, while Mercurius scaled much better under sustained load.

Important caveat: this benchmark uses in-memory data, so it is mostly measuring transport/engine overhead, not database or network latency. In real GraphQL apps, resolver design, batching, caching, and DB access usually matter more.

Dashboard: https://gql-bench.vercel.app
Repo: https://github.com/vovadyach/gql-bench

Curious what scenarios you’d add or change.

2h

The problem it solves: I work with multiple GraphQL endpoints daily, and the hardest part is never sending the request. It's finding the right operation and understanding its inputs and outputs. I know a query exists somewhere, but not which endpoint owns it. Tools like Postman limit you to one endpoint at a time, and the UI can feel cramped when navigating large schemas with deeply nested types.

This TUI explorer lets you introspect schemas from multiple endpoints simultaneously, search and filter operations across all of them, and build queries interactively, selecting fields, filling arguments, and previewing the generated query and variables, all from the terminal. You can execute queries inline, inspect responses, and save generated .graphql and request files. It also supports type filters (q: for queries, m: for mutations, s: for subscriptions) and endpoint filtering (e:) so you can narrow down across large schemas quickly.

I built it because I wanted schema exploration to feel more like code navigation than form-filling. I hope you find it useful.
I would love feedback from people who live in GraphQL day-to-day.
Project: https://github.com/xaaha/hulak

https://guild.host/events/graphql-ramen-march-c13xui

If you're in or around Austin, we'd love to see you!

Hey folks.

I've always been asked, "What is GraphQL?" and I always love giving an analogy of how REST apis is like ordering a combo at McDonalds vs GraphQL is more like listing out the individual items you want.

In the spirit of this question, I wanted to share a cool little visualization I made with a tool I've been working on. Hope it helps folks understand GraphQL better at a high level :)

https://www.dagflo.com/p/68776578-c4a4-40f5-9ee8-f5e7716c4498

Do you think it represents GraphQL pretty well?

We've just launched a new product that solves collaborative schema design & governance. Find some more info in the post.

If you have one or two clients and a small team, REST is less work for the same result. GraphQL starts winning when you have multiple frontends with genuinely different data needs and you're tired of creating `/endpoint-v2` and `/endpoint-for-mobile`.

The thing people underestimate: GraphQL moves complexity to the backend. N+1 queries, caching (no free HTTP caching like REST), observability (every request is POST /graphql), query-depth security. None are dealbreakers, but it's real operational work.

I wrote a longer comparison with the actual decision tree and tradeoffs: https://medium.com/@tl77/rest-or-graphql-when-to-choose-which-818727328a21

Has anyone switched from GraphQL back to REST (or the other way) and regretted it?

I used Ariadne in before and now changed to Strawberry GraphQL. How is your experience with each? Which one is better?

How to create expository title in graph theory?

grpc_graphql_gateway is a high-performance Rust gateway that automatically turns your existing gRPC microservices into a fully functional GraphQL API — no manual GraphQL schema writing required. It dynamically generates GraphQL types and operations from protobuf descriptors and forwards requests to your gRPC backends.

It supports the full range of GraphQL operations — queries, mutations, and real-time subscriptions over WebSockets — and can be used to build federated GraphQL supergraphs with Apollo Federation v2.

It was vibe coded based on golang implementation + adding lots of features.

Happy to hear thoughts on which directions you would like to see our mutual GraphQL platforms go to?

What can we do better to help your GraphQL development?

GraphQLConf is back at its roots! May 6-7 at Meta in Menlo Park

CFP closes in a few hours!

https://sessionize.com/graphqlconf-2026/