BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

Choose your language

InfoQ Homepage News Netflix Open Sources Their Domain Graph Service Framework: GraphQL for Spring Boot

Netflix Open Sources Their Domain Graph Service Framework: GraphQL for Spring Boot

This item in japanese

Bookmarks

Within a few months of implementing their Domain Graph Service (DGS) framework, Netflix has open-sourced DGS to the Java community. This framework makes it easier to implement GraphQL in a Spring Boot application and is suited for both standalone and federated GraphQL services. DGS supports the GraphQL Federation to create one unified API gateway which, in the background, calls the various services required by the specific query.

The DGS framework is based on Spring Boot’s annotation-based model. A unit test framework is provided as well as integrations with Spring Security. Monitoring is available through metrics and tracing features.

DGS is used within Netflix and the various features are thoroughly tested. Under the hood, DGS uses the graphql-java library. Netflix recommends a schema-first development approach to define the contract. Tooling can be used to consume the schema. Backward compatibility is important, especially with a federated GraphQL setup, and can be verified by comparing the different schema versions.

As an alternative to REST, GraphQL solves the issue of over-fetching or under-fetching data. Over-fetching is fetching all the data from an endpoint, but using only a portion of that data for, say, a mobile application. This requires filtering and leaving the remaining data unused. Under-fetching is fetching all the data from an endpoint, but not having enough data. This usually requires a call to a second endpoint. For example, consider an endpoint, /student. One user might want to retrieve all the student’s email addresses while another user might want to retrieve the various classes in which the students are enrolled.

Alternatively to schema-first development, the DGS framework supports code-first development. With this approach, the schema is generated during runtime based on the definitions in the code.

Implementing DGS starts with defining a schema that defines the API. The DGS Code Generation plugin for Gradle can be used to generate the API based on the following Movie and Query objects.

type Query {
    movies(titleFilter: String): [Movie]
}

type Movie {
    title: String
    ...
}

The API is implemented by using a Data fetcher. Methods annotated with @DgsData implement an optional data fetcher for a field.

@DgsComponent
public class MoviesDatafetcher {


    private final List<Movie> movies= 
      List.of(
         new Movie("The Hitchhiker's Guide to the Galaxy", 2005)
     );


    @DgsData(parentType = "Query", field = "movies")
    public List<Movie> movies(@InputArgument("titleFilter") String titleFilter) {
        if(titleFilter == null) {
            return movies;
        }


        return movies.stream()
            .filter(s -> s.getTitle().contains(titleFilter))
            .collect(Collectors.toList());
    }
}

After starting the Spring Boot application, the /graphql endpoint is available. A GraphiQL query editor is provided via the /graphiql endpoint. Various features are available to extend the example such as security, metrics and tracing.

InfoQ spoke to Paul Bakker, senior software engineer at Netflix and committer for DGS.

InfoQ: How's the adoption of DGS within Netflix? Are most services already using it?

Paul Bakker: We started developing the DGS framework about 18 months ago. We have about a hundred teams using it, and that number is growing almost every day. Many DGSs are part of a federated graph to support our ecosystem of "studio" apps. We also see a lot of usage for standalone services and are experimenting with using GraphQL in the core Netflix service as well.

InfoQ: Which are the best use-cases for DGS?

Bakker: GraphQL works really well for providing a flexible API that’s usable by multiple clients/devices. Basically, anything where you would previously use REST. On top of that, we’re very excited about the GraphQL Federation, which is a great way to create an API layer on top of many microservices. Note that the federation is completely optional for DGS, but it works well together.

If you’re using Java with Spring Boot, then DGS provides a great way to develop GraphQL.

InfoQ: Are there cases where you wouldn't recommend using GraphQL or DGS?


Bakker: At Netflix, we primarily use gRPC for server to server communication and don’t intend to change that. This is more about the preference for API style than anything else though, so it’s more because we have a really great existing ecosystem. The most important question to ask yourself is if the intended users of your API are prepared to use GraphQL.

The DGS framework is developed specifically for Spring Boot, so that’s a requirement.

InfoQ: What was the most challenging feature to implement and why?


Bakker: Getting started developing a framework like this is easy, but getting it to work well for a broad variety of users and use cases is hard. It takes time to explore use cases and a lot of interaction with users. Basically, it took us 18 months to get where the framework is now, and there aren’t really any shortcuts.

From a more technical perspective, getting code generation (which is optional, but very useful for DGS) to work well was hard. Writing and testing "meta code" is hard to wrap your head around, and there seems to be an infinite number of corner cases to account for.

InfoQ: How's the community feedback so far? Did you get interesting feature requests?

Bakker: It’s been only a week since we announced open-sourcing DGS, but community engagement has been overwhelming already, and very positive. We’re getting lots of questions from folks who are trying it out. We’re already using this feedback to improve the documentation further, filling in any gaps based on the on-going discussions. Some great ideas for new features as well. This type of engagement is really the main reason we decided to open source, to make the framework better for everyone by learning from more users.

InfoQ: Which new features can we expect in the future?

Bakker: Support for WebFlux is one thing we’re expecting to add. Currently, we’re not using WebFlux at Netflix yet, mostly because of other parts of the infrastructure, but that’s going to change. Other than that, it will be many more incremental added features and improvements, similar to what we’ve done in the last 18 months.

Netflix DGS is available as open-source on GitHub under the Apache 2.0 license.

Netflix DGS is available as open-source on GitHub under the Apache 2.0 license.

Rate this Article

Adoption
Style

Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • High I/O

    by Owen Rubel,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    This methodology requires high I/O; it uses a non-paralellized separate request/response for each api call from the Graphql layer to accomplish the task.

  • Oh rest.

    by Mac Noodle,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    The problem is assuming rest is the right way to implement an endpoint. It it is not. It sounds good on paper but in reality it is not. The right thing to do is expose the right amount of data for the right requests. At the same time graphql is not the solution to this problem. If you're going to allow arbitrary queries to your data graph just expose the database as SQL. And no don't do that either.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

BT