WebSockets Next client: make it possible to customize the WebSocketConnectOptions and WebSocketClientOptions

[mkouba]

Description

It might be useful to be able to customize the WebSocketConnectOptions and WebSocketClientOptions. There are options that should be always overriden by the WebSocketConnector API (uri, host, etc.) but others could be set directly.

Implementation ideas

No response

[michalvavrik]

Should this work similarly to how Vert.x HTTP Server options are customized https://github.com/quarkusio/quarkus/blob/main/extensions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/HttpServerOptionsCustomizer.java ? Do I simply expose interface, allow users to create a CDI bean implementing it and then make sure that some configuration like uri / host etc. is overwritten by Quarkus WS Next extension @mkouba ? I am interested :-)

[mkouba]

Should this work similarly to how Vert.x HTTP Server options are customized https://github.com/quarkusio/quarkus/blob/main/extensions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/HttpServerOptionsCustomizer.java ? Do I simply expose interface, allow users to create a CDI bean implementing it and then make sure that some configuration like uri / host etc. is overwritten by Quarkus WS Next extension @mkouba ?

Hm, I was originally thinking about setting a customizer directly on a WebSocketConnector so that you can create multiple WS connections with different configurations. If we stick with a bean implementing an interface then we would not be able to customize per connection, max per client endpoint. The question is whether it's actually needed.

I am interested :-)

👍

[michalvavrik]

Should this work similarly to how Vert.x HTTP Server options are customized https://github.com/quarkusio/quarkus/blob/main/extensions/vertx-http/runtime/src/main/java/io/quarkus/vertx/http/HttpServerOptionsCustomizer.java ? Do I simply expose interface, allow users to create a CDI bean implementing it and then make sure that some configuration like uri / host etc. is overwritten by Quarkus WS Next extension @mkouba ?

Hm, I was originally thinking about setting a customizer directly on a WebSocketConnector so that you can create multiple WS connections with different configurations. If we stick with a bean implementing an interface then we would not be able to customize per connection, max per client endpoint. The question is whether it's actually needed.

It would be good to be able to customize per connection if there or at least per client endpoint. I need to have a look how would it look like and get back to you.

[mkouba]

or at least per client endpoint

For client endpoints it should be straightforward to filter by io.quarkus.websockets.next.WebSocketClient.clientId().

[michalvavrik]

@mkouba I had a look and I don't see why it wouldn't be possible to apply customizer beans depending on boolean appliesTo(String endpointId) or boolean appliesTo(String clientId) method. Default method will return true so applies to everything. If you think it is desirable to have additional method parameters apart of clientId / endpointId like request details (headers, exact path with resolved path params etc.) I can try to find a way to do that as well. Basically what I am asking is - it will be customer instances and we will apply them if they say "yes, it applies". If you have a different idea, just let me know, I am happy to do this differently, just need a clue.

[mkouba]

@mkouba I had a look and I don't see why it wouldn't be possible to apply customizer beans depending on boolean appliesTo(String endpointId) or boolean appliesTo(String clientId) method. Default method will return true so applies to everything. If you think it is desirable to have additional method parameters apart of clientId / endpointId like request details (headers, exact path with resolved path params etc.) I can try to find a way to do that as well. Basically what I am asking is - it will be customer instances and we will apply them if they say "yes, it applies". If you have a different idea, just let me know, I am happy to do this differently, just need a clue.

It's definitely possible. My point is that we could add something like WebSocketConnector#customizeOptions(BiConsumer<WebSocketConnectOptions,WebSocketClientOptions>) instead of invoking beans that would need the appliesTo logic etc.

[michalvavrik]

The WebSocketConnector#customizeOptions(BiConsumer<WebSocketConnectOptions,WebSocketClientOptions>) or something like this on WebSocketConnector sounds much better than my suggestion, but I think it would be nice to have something that works for both client and server endpoints same. If endpoints could optionally declare method like this:

@ ConnectionOptions  // or maybe just @ Customize for future enhancements
WebSocketClientOptions clientOptions(WebSocketConnectOptions connectOptions) {
  return new WebSocketClientOptions();
}

it seems easy as well. Or maybe you have further suggestions how to deal with server endpoint connections?

[mkouba]

but I think it would be nice to have something that works for both client and server endpoints same.

But you don't need anything for the server endpoint, or am I missing something?

[michalvavrik]

Alright, so WebSocket client has options while server endpoint parameters are already configurable by HttpServerOptionsCustomizer (e.g. io.quarkus.websockets.next.runtime.WebSocketHttpServerOptionsCustomizer). Sorry I missed it. Let's go with your suggestion.

[mkouba]

Alright, so WebSocket client has options while server endpoint parameters are already configurable by HttpServerOptionsCustomizer (e.g. io.quarkus.websockets.next.runtime.WebSocketHttpServerOptionsCustomizer). Sorry I missed it. Let's go with your suggestion.

Ok, I'm glad we're on the same page now 😉 .

[deripas]

Yes, I also encountered the need to customize WebSocketConnectOptions, for example, to disable allowOriginHeader.