websockets

[bgwdotdev]

Here's a first pass, scrappy implementation of mists websockets into wisp. #10

Still figuring out if there's a better way to do this and discussing with rawhat a little on approaches.

This currently works though. Feedback on approach most welcome.

Option was only added due to the test stuff, not sure how do deal with that yet but maybe that's solving the wrong problem.

[bgwdotdev]

I've now created a pure wisp public api for this which mostly wraps the mist types.

Docs (and likely type names/api) still need work but wanted to verify if the approach is more suitable for wisp before attempting to polish things.

Hopefully the Socket type would allow wrapping various connection types that may be required by potentially different backends as appropriate?

Let me know if I'm on the right track or missing a beat.

Thanks :)

[bgwdotdev]

Okay. Had a big stab at moving all the mist stuff into a separate module.

I've fully removed the import mist from the main wisp.gleam file.

Websockets are also now implemented with a reference example in the test file.

I've had to make a couple things in the wisp.gleam file public that I'm not sure we want to keep that way (mostly around make_connection).

Everything needs a tidy, documentation and the test cases fleshed out but hopefully it's looking more like how we want it to be ^^?

Definitely not finished working on it (want to try dump mist from internal somehow) but keen to take any feedback generally at this stage!

[bgwdotdev]

Okay! I think I'm feeling happy with the general api design and split of things now and was thinking of moving on to docs.

I was thinking of creating a websocket error type within wisp as well for when wisp_mist.send fails, though looking at the errors provided from mist via glisten, I'm thinking we might want to just cover important ones like Closed and Timeout maybe and then the others can fall under some more generic socket error that left for the user to handle? (here's the variants for reference https://hexdocs.pm/glisten/3.0.0/glisten/socket.html#SocketReason)

[bgwdotdev]

left to do:

• update examples to use wisp_mist.handler
• write example using websocket

done?

[bgwdotdev]

Thanks for the feedback+review, been busy with work so not been able to progress it, off next week though so will try push this along to finish line and address all your notes :)! Much appreciated.

[bgwdotdev]

the mist module split only has now been created as another pr ahead of the work here if we want to tackle that bit first :)

[bgwdotdev]

just as a note, rebase off main now so diff should be easier

[bgwdotdev]

Ok, I think I've updated everything! docs, examples, tests hopefully all covered :)

Assuming there was no further changes required, the only issue left I think would be how we want to do errors. I'm not happy with the error handling I've added but also not sure we want to copy all the errors available in the mist implementation. If you have an idea on how you'd prefer this was present to the user, happy to follow that :)

otherwise if just translating over all the glisten socket errors makes sense then happy to do that as well: https://hexdocs.pm/glisten/3.0.0/glisten/socket.html#SocketReason

[lpil]

Have just been giving this a try. How does one create more than one webhook handler? The type parameter means they have to all have the same types, so I can't create a second one for another route.

[bgwdotdev]

Yeah, this is exactly the big problem and sticking point I can't find away around in this ( or any I can think of :( ) design without leaking mist types into wisp/user applications.

Essentially, you'd have to make each websockets type present in a single sum type for each the message and state as we're currently forced to lock in the WsCapability type in the handler.

I explored "safely" casting the types under the hood which while it worked and I believe was safe from being able to be misused, as you've previously stated and I do agree with, it does undermine the type system and a solution away from this would be the way to go.

Unfortunately I can't seem to find a way to set this type any later or earlier than the handler without leaking mists connection. It's probably a skill issue but I've gone over it and over it many times to no avail sadly.