Subscription connection parameters support

[HaraldNordgren]

Adds support for subscription (websocket) connection parameters support.

We are having an issue with authorization when using subscriptions in genqlient. Our mobile app team is using Apollo for GraphQL requests, and Apollo seems to sends its auth in a way that is different from how genqlient does it:

https://www.apollographql.com/docs/react/data/subscriptions#5-authenticate-over-websocket-optional

This is causing a problems, because we use genqlient for testing the backend. It seems that the way Apollo is implemented, authentication (and other headers) are not actually sent as HTTP headers, but as connection parameters instead.

I have:

• Written a clear PR title and description (above)
• Signed the Khan Academy CLA
• Added tests covering my changes, if applicable
• Included a link to the issue fixed, if applicable
• Included documentation, for new features
• Added an entry to the changelog

[HaraldNordgren]

Since there was never a a release that includes NewClientUsingWebSocket, we should be free to update the signature if we want, and possible only have one function:

func NewClientUsingWebSocket(endpoint string, wsDialer Dialer, headers http.Header, connParams map[string]any) WebSocketClient

[HaraldNordgren]

A big gotcha regarding HTTP headers and connection parameters, that I realized recently, is that websocket requests in 99desgins gqlgen enter a different path, going through here:

	gqlgenServer.AddTransport(transport.Websocket{
		InitFunc: func(ctx context.Context, initPayload transport.InitPayload) (context.Context, *transport.InitPayload, error) {
			// initPayload contains connection parameters
		},
	})

than the middleware path that would normally be expected:

	r.With(ah.VerifyAuthMiddleware).Method(http.MethodPost, "/v1", c.GraphServer)
	r.With(ah.VerifyAuthMiddleware).Method(http.MethodGet, "/v1", c.GraphServer)

[HaraldNordgren]

Ping @benjaminjkraft and @matthieu4294967296moineau, do you think it would be possible to get a quick look here? 🤗

[jbaldwinroberts]

this would be useful for us too - thanks

[HaraldNordgren]

Hi @benjaminjkraft, I know you are likely very busy. But it would be much appreciated to get some review here 🤗

[benjaminjkraft]

Sorry for the delay, it's been a busy month. This seems ok, but I wonder if now is the right time to add a more extensible options interface, either an options struct, or functional-style options, either of which could incorporate the optional headers as well. That way we don't end up having to add a ton of different functions over time.

[HaraldNordgren]

@benjaminjkraft Hope everything is under control and not too stressful 🤗 Thank you for reviewing here, much appreciated!

I think it's a great point regarding options. I have pushed a new version with this added. Let me know what you think!

[HaraldNordgren]

I never figured out a way to generate the 99designs/gqlgen code for countAuthorized. Running go generate ./... even on the main branch fails for me.

So I created countAuthorized infrastructure myself. I hope didn't introduce any issues. All the tests are passing at least 😃

[benjaminjkraft]

Huh, go generate ./... should work! It works for me. Adding -v -x may make any issues clearer, you can see what packages and commands it's finding. Anyway, you got it right except for one line of whitespace :-) .

On the actual changes, this looks great. I'm not sure if we should change headers to be an option as well, since it's optional. I think I would incline towards yes. As long as it's a 1:1 replacement we can probably just change the existing API since as you say there hasn't been a release, then we don't have to have two. But if you see a reason not to I'm also ok to merge this as-is.

[HaraldNordgren]

@benjaminjkraft I think it does make sense with the headers.

But it feels a bit tricky to get it right with the important "Sec-WebSocket-Protocol" key, which should always be present in the output. Maybe better to do as a follow-up?

[benjaminjkraft]

Oh, I see what you mean. Sure, I'll merge this and if we sort it out before we cut a release great, and if not oh well.

[HaraldNordgren]

Thanks a lot @benjaminjkraft 🚀

[benjaminjkraft]

Thank you!!