A Java code-first type-safe GraphQL Client API suggestion for Microprofile GraphQL Issue #185.

Basic Usage

Creating the client-side counterpart of the GraphQL API:

package examples.typesafeclient;

import io.smallrye.graphql.client.typesafe.api.GraphQLClientApi;

import java.util.List;

@GraphQLClientApi
public interface SuperHeroesApi {

    List<SuperHero> allHeroesIn(String location);

}

A model class:

package examples.typesafeclient;

import java.util.List;

public class SuperHero {

    private String name;
    private List<String> superPowers;

    // plus getters and setters

}

Injecting the client using CDI and using it:

package examples.typesafeclient;

import javax.inject.Inject;
import java.util.List;

public class MyClientUsage {

    @Inject
    SuperHeroesApi superHeroesApi;

    public void execute() {
        List<SuperHero> allHeroes = superHeroesApi.allHeroesIn("Outer Space");
        // ...
    }

}

• The default request type is query. To make it a mutation, annotate it @Mutation. The parameter name is only available if you compile the source with the -parameters option. Otherwise, you’ll have to annotate all parameters with @Name.

The example above uses CDI, e.g. when you are in a MicroProfile or Jakarta EE environment. If you are in an environment without CDI support, you need to instantiate the API interface by using the builder:

SuperHeroesApi api = TypesafeGraphQLClientBuilder.newBuilder().build(SuperHeroesApi.class);

The basic idea of the Java code-first approach is that you start by writing the DTOs and query/mutation methods as you need them in your client. This ensures that you don’t request fields that you don’t need; the thinking is inspired by Consumer Driven Contracts.

If the server uses names different from yours, you can simply use annotations to do a mapping:

Name Mapping / Aliases

If the server defines a different field or parameter name, annotate it with @Name. If the server defines a different query name, annotate the method as, e.g., @Query("findHeroesCurrentlyLocatedIn").

By renaming methods, you can also define several variations of the same request but using different return types or parameters. E.g.:

public interface SuperHeroesApi {
    SuperHero findHeroByName(String name); 

    @Query("findHeroByName")
    SuperHeroWithTeams findHeroWithTeamsByName(String name); 
}

• The SuperHero class has no team affiliations (for this example).

• The SuperHeroWithTeams class has a List<Team> teamAffiliations field. The actual query name is still findHeroByName. The Team class doesn’t contain the members to break recursion.

If you rename a field or method, the real field or method name will be used as an alias, so you can select the same data twice (see and below).

Configuration

If the endpoint is always the same, e.g. a public API of a cloud service, you can add the URL to your API annotation, e.g.:

@GraphQLClientApi(endpoint = "https://superheroes.org/graphql")
interface SuperHeroesApi {
}

When instantiating the API with the builder, you can set (or overwrite) the endpoint there:

SuperHeroesApi api = TypesafeGraphQLClientBuilder.newBuilder()
    .endpoint("https://superheroes.org/graphql")
    .build(SuperHeroesApi.class);

Commonly you’ll need different endpoints, e.g. when you need one endpoint for your production system, but a different endpoint for your test system. Simply use MicroProfile Config to set the endpoint; similar to the MicroProfile Rest Client, the key for the endpoint is the fully qualified name of the api interface, plus /mp-graphql/url, e.g.:

org.superheroes.SuperHeroesApi/mp-graphql/url=https://superheroes.org/graphql

If you want to use a different key, set the base config key on the annotation @GraphQLClientApi(configKey = "superheroes"); then use this key for the endpoint superheroes/mp-graphql/url.

When using the builder, you can override the config key as well: TypesafeGraphQLClientBuilder.newBuilder().configKey("superheroes").

NestedParameter

Some APIs require parameters beyond the root level, e.g. for filtering or paginating nested lists. Say you have a schema like this:

type Query {
    team(name: String!): Team!
}

type Team {
    members(first: Int!): [SuperHero!]!
}

To pass the parameter to the nested field/method, annotate it as @NestedParameter, e.g.:

@GraphQLClientApi
interface TeamsApi {
    Team team(String name, @NestedParameter("members") int first);
}

The value of the @NestedParameter annotation is the dot-delimited path to the nested field/method that the value should be added to.