Spring for GraphQL

• Schema-first SDL mit types, queries und mutations.
• @Controller mit @QueryMapping und @MutationMapping.
• DataLoader gegen N+1-Probleme.
• Security auf Feld- oder Resolver-Ebene.
• Persisted Queries und Operation Monitoring.

• Frontend-Teams brauchen flexible, aggregierte Read Models.
• Mobile Clients sollen mehrere REST Roundtrips vermeiden.
• Du kontrollierst Schema-Governance und Performance.

• GraphQL direkt auf JPA Entities spiegeln.
• N+1 Resolver ohne DataLoader.
• Unbegrenzte Query-Tiefe und fehlendes Rate Limiting.

Alte Portal-Backends können über GraphQL moderne BFF-Schichten erhalten, ohne sofort alle Backend-Systeme neu zu bauen.

Das Beispiel zeigt bewusst nicht nur Annotationen, sondern auch die Verantwortung der Schicht. In echten Projekten sollte der technische Spring-Code an Adapter- oder Konfigurationsrändern bleiben, während die Fachlogik testbar und möglichst frameworkarm bleibt.

@Controller
class OrderGraphQlController {
    private final OrderQueryService queries;

    @QueryMapping
    OrderView order(@Argument UUID id) {
        return queries.findOrder(id);
    }

    @SchemaMapping(typeName = "Order", field = "customer")
    CompletableFuture<CustomerView> customer(OrderView order, DataLoader<String, CustomerView> loader) {
        return loader.load(order.customerNumber());
    }
}

• Ist die Verantwortung des Bausteins klar: Framework steuert Lebenszyklus, Library wird gezielt benutzt?
• Ist die Fachlogik außerhalb von Controller, Listener, Repository-Implementierung oder Konfiguration?
• Sind Fehlerfälle, Timeouts, Security, Monitoring und Tests sichtbar modelliert?
• Gibt es klare Grenzen zwischen DTO, Domäne, Persistence und Infrastruktur?