# Netflix DGS Framework: a GraphQL server for Spring Boot, built on annotations

> The DGS Framework packages graphql-java into a Spring Boot programming model with annotated data fetchers, code generation from schema, Federation support and a query test harness. It is aimed at JVM teams already on Spring, and it inherits Spring's version treadmill as a result.

**Netflix/dgs-framework** — GraphQL for Java with Spring Boot made easy.

- Repository: https://github.com/Netflix/dgs-framework
- Website: https://netflix.github.io/dgs
- Stars: 3,398 · Forks: 343
- Language: Kotlin
- License: Apache-2.0
- Published: 2026-09-23 · Updated: 2026-09-23 · Language: en
- Canonical page: https://hysenlabs.com/projects/netflix-dgs-framework

## What the DGS Framework is for

DGS stands for Domain Graph Service, and the name describes the intended shape of the system: one GraphQL service per domain, composed at the gateway through GraphQL Federation. Netflix built the framework for that topology, and the README lists easy integration with GraphQL Federation as a headline feature rather than an add-on.

The audience is narrow and specific. You need to be writing a JVM service on Spring Boot, and you need to expose GraphQL rather than REST. If you are starting a GraphQL server in Go, Node or Python, nothing here applies. If you are on plain Java without Spring, the annotation programming model that defines the project is not available to you, even though the underlying graphql-java library is.

The framework is written primarily in Kotlin but targets Java consumers, which is why the repository carries parallel example projects such as graphql-dgs-spring-graphql-example-java and graphql-dgs-spring-graphql-example-java-webflux. The README describes the programming model as annotation based, and that is the core of the pitch: you write a Spring component, annotate a method, and it becomes a data fetcher.

## How DGS wires schema, fetchers and the runtime

The architecture is a thin Spring layer over graphql-java. The repository layout shows the split: graphql-dgs holds the core runtime, graphql-dgs-spring-graphql and graphql-dgs-spring-graphql-starter hold the Spring Boot integration, graphql-dgs-client provides a client, and dgs-starter and dgs-starter-test are the convenience starters.

A DGS service is built from three pieces. A GraphQL schema file describes the types and queries. A Spring component annotated as a query or mutation handler supplies the resolver logic. The framework scans for those components at startup, binds them to the corresponding schema fields, and serves the resulting executable schema over HTTP.

Around that core sit optional modules that map to the feature list. graphql-dgs-pagination, graphql-dgs-extended-scalars and graphql-dgs-extended-validation add schema-level behaviour. graphql-dgs-spring-boot-micrometer wires metrics into Spring Boot's actuator instrumentation. graphql-dgs-subscription-types covers subscriptions over WebSockets and SSE. graphql-dgs-reactive targets reactive stacks, which is why a WebFlux example exists alongside the servlet one.

The design decision worth naming is that DGS does not ask you to hand-maintain Java types for every schema type. The Gradle code generation plugin generates types from the schema, so the schema stays the source of truth. That is a real convenience at scale, and it also means your build now has a code generation step that must stay in sync with the schema.

## Installing DGS and writing a first query

The README does not inline installation steps. It points to the getting started guide at https://netflix.github.io/dgs/getting-started/, and the README's own getting started section does the same. The repository layout indicates the dependency coordinates live in the platform modules, graphql-dgs-platform and graphql-dgs-platform-dependencies, which is consistent with the search phrase people use for the BOM. Because the README does not print a dependency block, the exact version string and artifact coordinates should be taken from the getting started guide and the published platform module rather than guessed.

The shape of a DGS service, however, is visible from the starter modules and the example projects in the repository. A Spring Boot application adds the DGS starter, places a schema file on the classpath, and defines annotated handler components.

```bash
./gradlew build
```

The repository's Makefile defines the tasks used to work on the framework itself rather than on a consumer application. Running make format calls ./gradlew formatKotlin to format source, and make publish-local runs a clean build followed by publishToMavenLocal so the code generation artifacts are available locally as a SNAPSHOT. That second target is the one that matters if you are testing codegen changes against the bundled examples.

```bash
make publish-local
```

For a consuming application, the practical first step is to add the DGS starter and a schema file, then write one annotated fetcher and run the application. The README lists a test framework for writing query tests as unit tests, and the dgs-starter-test and graphql-dgs-spring-graphql-starter-test modules exist precisely so that query tests can run inside the normal test task rather than against a deployed server. That is the part of the framework that changes day-to-day development most: schema and resolver changes can be validated without standing up an HTTP endpoint.

## Where DGS gets awkward

The clearest limitation is the version coupling. The README's compatibility table ties DGS 11 and later to Spring Boot 4, DGS 10.x to Spring Boot 3, and DGS 5.x to Spring Boot 2. The status column states that 10.x will receive backports only until the second half of 2026, and that 5.x is no longer maintained. A team on Spring Boot 2 therefore has no supported DGS path, and a team on Spring Boot 3 has a dated one. Upgrading DGS is not an isolated dependency bump; it is an upgrade of the Spring Boot line underneath it.

There is also a ceiling on what the framework can hide. DGS is a Spring layer over graphql-java, so the execution semantics, the schema definition language and the resolver contract come from graphql-java and the GraphQL specification rather than from DGS. When execution behaves unexpectedly, the answer frequently sits below the DGS abstraction, and the annotation model does not remove the need to understand the layer underneath.

Finally, the framework assumes a particular architecture. Federation is listed as an easy integration, and the Domain Graph Service naming makes the intended deployment a set of small graph services behind a gateway. A single monolithic GraphQL endpoint that has no intention of federating still works, but it pays for a framework whose design centre is elsewhere. The README does not document rollback behaviour for schema changes, and it does not describe a migration path between DGS major versions beyond the compatibility table.

## DGS against Spring GraphQL

The most direct alternative is Spring GraphQL, the Spring project for GraphQL servers. The difference in approach is ownership of the programming model. Spring GraphQL follows the Spring portfolio convention: you configure an execution strategy and wire schema resources through Spring's own abstractions, with the framework staying close to the underlying graphql-java API. DGS instead defines its own annotation-driven model on top of graphql-java, and adds a code generation plugin, a dedicated query test harness and first-class Federation integration as part of the framework rather than as separate concerns.

That distinction matters in practice. Choosing DGS means adopting a Netflix-flavoured convention set with its own starters, its own test module and its own codegen step. Choosing Spring GraphQL means staying nearer to the Spring GraphQL project's release cadence and to graphql-java directly, at the cost of assembling code generation and query testing yourself. Neither is a strictly better answer; they are different bets about how much convention you want imposed.

The search phrase comparing the two is a reasonable one to have in mind, because the decision usually comes down to whether the codegen plugin and the Federation integration are worth taking on a second framework's upgrade schedule alongside Spring Boot's.

## Maintenance, licensing and upgrade cost

The repository is not archived, and the last push was on 2026-09-21, two days before this was written. The most recent release is v12.1.0 from 2026-09-16, following v12.0.1 in May 2026 and v12.0.0 in April 2026. That is a steady release rhythm on the current major line, and the README's own table labels DGS 11 and later as actively maintained.

The upgrade cost is concentrated in the Spring Boot pairing. Because DGS 11 and later require Spring Boot 4, moving to the current DGS line means moving to the current Spring Boot line. Teams that track Spring Boot closely will find DGS follows; teams that deliberately lag on Spring Boot will find themselves on a DGS version with a stated end date for backports. That is a planning constraint, not a defect.

The project is licensed under Apache-2.0, and the repository carries a LICENSE and a NOTICE file at the top level. Apache-2.0 is a permissive licence that permits commercial use and modification, and the NOTICE file is the mechanism by which attribution obligations are typically carried. What that means for your distribution or your modified fork depends on your circumstances, so read the LICENSE and NOTICE text in the repository rather than a summary of it. Nothing here is legal advice.

The version compatibility table in the README is the single most useful file for planning an upgrade, because it states the support window for each DGS line in plain terms rather than leaving it to be inferred from release dates.

## Conclusion

Adopt DGS if your services are already Spring Boot applications and you need Federation or subscription support without leaving the Spring programming model. Do not adopt it if you are not on Spring, or if you are still on Spring Boot 2: the version compatibility table marks DGS 5.x as no longer maintained, and 10.x only receives backports until the second half of 2026. Before committing, check that the Spring Boot line you run matches the DGS major version you plan to use, and read the getting started guide at netflix.github.io/dgs for the current setup steps.

## FAQ

### What does DGS stand for in the Netflix DGS Framework?

DGS stands for Domain Graph Service. The README describes the project as a GraphQL server framework for Spring Boot developed by Netflix, and the name reflects the intended deployment of one graph service per domain.

### Can Spring be used with GraphQL?

Yes. The DGS Framework is a GraphQL server framework for Spring Boot, and the README lists an annotation based Spring Boot programming model as its first feature, alongside integration with Spring Security.

### What is the DGS Framework?

It is a GraphQL server framework for Spring Boot developed by Netflix. Its features include annotated data fetchers, a test framework for query tests, a Gradle code generation plugin, GraphQL Federation integration, subscriptions over WebSockets and SSE, and file uploads.

## Sources

- [License: Apache-2.0](https://github.com/Netflix/dgs-framework/blob/master/LICENSE)
- [Netflix/dgs-framework on GitHub](https://github.com/Netflix/dgs-framework)
- [Project website](https://netflix.github.io/dgs)
- [README](https://github.com/Netflix/dgs-framework/blob/master/README.md)
- [Releases](https://github.com/Netflix/dgs-framework/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/netflix-dgs-framework