19 posts tagged with "Spring"

Every GraphQL client eventually has to pick between two HTTP methods, and both come with a problem attached. GET is safe and cacheable, but it puts the whole document into the URL. POST carries the document in a body, but HTTP has to assume that every POST might change something, so caches and retry logic stay away from it. In June 2026 the IETF published RFC 10008, which defines a third option: QUERY, a method that carries a body like POST and is safe and idempotent like GET. That description also fits a GraphQL query operation very closely.

Send a GraphQL server a document with a typo in it, and for most of the last decade the answer came back as 200 OK. Ask for a field that does not exist, and you got 200 OK. Run a query that half worked, and you got 200 OK again, with the bad news inside the body. Load balancers, CDNs and dashboards do not read response bodies, so to them all three requests looked like successes. The GraphQL over HTTP specification is getting its first edition, named September 2026, and its main job is to let the status code tell the truth again without breaking the clients that learned to ignore it.

For most GraphQL developers, "federation" has meant Apollo Federation: a set of directives, a _entities field in every service, and a router that stitches it all together. Other vendors built gateways that are compatible with Apollo's design. Under the GraphQL Foundation, a working group has worked since 2022 on a vendor-neutral specification for the same job. On 21 September 2026 that specification got a new name. The Composite Schemas specification is now the GraphQL Federation specification.

Two camps. One schema. Endless arguments on Twitter. Every Java GraphQL project, within the first week, has the same meeting: should we write the schema first in SDL, or should we write Java classes and let the schema fall out of them? Both camps are convinced the other is doing it wrong. Both are partially right. Here's the honest breakdown, the actual tradeoffs, and what the 2026 Java ecosystem looks like when you stop arguing and pick one.

For six years, the Java GraphQL world had two doors. Door One: Netflix DGS, born at a company whose entire product is one giant graph. Door Two: Spring GraphQL, blessed by the Spring team itself. Pick a door, write your code, and pray you never had to switch. Then somebody at Netflix and somebody at VMware had coffee, and the doors got knocked down. Here's what actually happened, what it means for your codebase, and whether you should care.

You know how most companies build a GraphQL API, hit some scaling issues, and then write a blog post about it? Airbnb took a different approach: they built an entire data-oriented service mesh, ran it for five years at massive scale, and then open-sourced it. Meet Viaduct - GraphQL's ambitious cousin who went to architecture school.

Your REST API is like a teenager: it only responds when you ask it something. Repeatedly. Every second. "Any new messages?" "No." "Any new messages?" "No." "Any new messages?" "STILL NO." Enter GraphQL Subscriptions - where your API finally grows up and learns to call YOU when something interesting happens.

Resolvers are where GraphQL magic happens - and where most bugs lurk. After years of debugging production resolvers at 2 AM, I've collected these dark arts. Use them wisely.

Your Spring GraphQL API works locally. Now let's make it production-ready with proper configuration, monitoring, security hardening, and operational best practices.

JPA entities and GraphQL types serve different purposes. Learn how to map between them efficiently while avoiding common pitfalls like lazy loading exceptions.