Websocket subscription client in Java (relates to #438)

[callumforrester]

Hi,

I have been using DGS for internal projects and have found myself in need of support for a subscription-over-websocket client that isn't Apollo.

I am considering having a go at implementing #438 to that end. A few questions to ponder, feedback welcome:

• Would such a contribution be welcome?
• Would it be acceptable to add spring-websocket as a dependency?
• Where should the code live? The client module? The websocket support module? A new module?
• What form should the response object take? I wondered about a GraphQLResponse whose getData() method returns a Flux but I'm sure there are many ways

[paulbakker]

Hi @callumforrester,

1. Yes, that would definitely be welcome! We want/need such a client as well but haven't had the time to implement it yet.

2. We're more and more standardizing on WebClient as the client. I believe WebClient can do WebSockets without the spring-websocket dependency, but obviously, that raises the question if WebClient can be a dependency of the client (it currently isn't).

3. This is much related to the previous question. I've been wondering if we should add a WebClient implementation out of the box (for normal requests), and wasn't sure about where to put it yet. A good option could be to make it a compileOnly dependency, and wire things conditionally in the auto configuration. If we go that route, WebClient can also be used for subscriptions.
   I would not put it in the websocket support module. Technically we have two of such modules (one based on WebFlux, one based on WebMVC), so that would make things difficult.

4)We could mimic the Server API, using a Publisher<ExecutionResult>. Basically similar to what you would use in a unit test: https://netflix.github.io/dgs/advanced/subscriptions/#unit-testing-subscriptions. What do you think?

[callumforrester]

Would it not be WebSocketClient rather than WebClient in this case? https://www.baeldung.com/spring-5-reactive-websockets

Agree with you and @berngp on returning a Publisher<ExecutionResult> from getData(), although there seems to be some debate on the best way to do this with WebSocketClient, which gives you a Mono.

[osi]

For the SSE subscription transport, there's little work required. We've done a simple implementation,

import org.springframework.core.ParameterizedTypeReference;
import org.springframework.http.MediaType;
import org.springframework.web.reactive.function.client.WebClient;
import reactor.core.publisher.Flux;
import reactor.core.scheduler.Schedulers;

import java.nio.charset.StandardCharsets;
import java.util.Base64;
import java.util.Map;

public class GraphQLSSEClient {
    private final WebClient webClient;

    public GraphQLSSEClient(WebClient webClient) {
        this.webClient = webClient;
    }

    public <T> Flux<T> subscribe(String query,
                                 String url,
                                 ParameterizedTypeReference<T> type)
    {
        return webClient.get()
                        .uri(url + "/subscriptions/sse?query={query}", Map.of("query", encodeQuery(query)))
                        .accept(MediaType.TEXT_EVENT_STREAM)
                        .exchangeToFlux(r -> r.bodyToFlux(type)
                                              .onBackpressureBuffer())
                        .publishOn(Schedulers.single());
    }

    private String encodeQuery(String query) {
        return Base64.getEncoder().encodeToString(query.getBytes(StandardCharsets.UTF_8));
    }
}

We're passing in Map<String,Object> as type, but that could be more sophisticated as @paulbakker mentioned, using ExecutionResult or another mechanism that'd allow mapping data but with a plainer representation for any errors

[berngp]

• +1 on adding a compileOnly dependency to org.springframework:spring-webflux on graphql-dgs-client.
• +1 on adding the specific components that help in this case via ConditionalOnClass, although I'm not sure how such components should look like.
• +1 on mimic the Server API, using Publisher<ExecutionResult>.
• Consider that both the RestTemplate and WebClient will be available in the classpath and therefore the supporting beans of both should be able reside in the same application context.

[callumforrester]

See #522 for a draft websocket implementation. Comments welcome, I will add tests etc. once the general approach is agreed-on.