Discussing about SSE implementation

[aesteve]

https://github.com/aesteve/vertx-sse

Project name

Vert.x SSE
Coordinates could be like : io.reactiverse:vertx-sse:1.0.0

Project goal

Provide a way to deal with Server-Sent-Events with Vert.x

Licensing

Apache 2.0

Motivation to the join the reactiverse

I'd like to open the discussion and hear about your opinion, more than really proposing it to the reactiverse directly.
The projects provides facilities to "plug" SSE implementation onto a vertx-web router, and also an EventSource client (based on Vert.x core).
Many possibilities :

1. Integrated into respectively vertx-web and vertx-core: Tests are depending on one another, (testing the EvenSource client impl agains the SSEHandler server-side implementation) so it makes it hard to cut the project in two parts. Moreover, it would "bloat" the core & web libraries with something a few people actually need.
2. An "official" module : why not. I'm not really sure if codegen would be useful in that case, but that's the only difference I may see with it being on the reactiverse. One good point though, would be version alignment with vertx-web and core.
3. Added to reactiverse

Existing implementation

https://github.com/aesteve/vertx-sse
You'll find an example you can open in your browser.
There's actually not that much code to maintain, and the SSE spec shouldn't change that much. Most of the work I did was fixing bugs (connection closed, etc.), or aligning with latest vertx-versions.

Please let me know if you think it's a good fit or not.

Thanks :)

[tsegismont]

Thanks for proposing this.

Can you provide some use cases when the SockJS support from vertx-web would not be appropriate?

[aesteve]

I don't know much about SockJS, but how would you configure it from Vert.x server-side to handle only uni-directional data ? (i.e. to not accept incoming data from user's browser, to prevent user to connect to your endpoint using a websocket ?).

I don't really know if you can configure Vert.x SockJSHandler to say "you should only allow users to connect through SSE on this endpoint, not through websockets" for say, preventing a malevolent user to connect to your SSE endpoint and push fake data continuously (DDOS issue maybe ?).

If it's possible, then perfect, SockJS support is probably more generic.

Note: Same goes for the eventbus bridge. I guess it might be possible to forward data in only one-way from event-bus to SSE using the SockJSHandler and Inboud/outboud permissions ? Maybe ? But never tried it myself.

[jponge]

I personally like SSE.

We could have your module as a reactiverse project, but why not have it in vertx-web?

In the Vert.x book I have a chapter where an (incomplete) implementation of SSE is done. It's such a useful yet simple protocol...

[vietj]

agreed with Julien Ponge. I think it was rejected at some time and I believe that @pmlopes can elaborate on the $subject Julien

…

On 28 Jan 2019, at 13:41, Julien Ponge ***@***.***> wrote: I personally like SSE <https://www.w3.org/TR/2009/WD-eventsource-20090421/>. We could have your module as a reactiverse project, but why not have it in vertx-web? In the Vert.x book I have a chapter where an (incomplete) implementation of SSE is done. It's such a useful yet simple protocol... — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANxiogTYDfOa9mUx2p3FRYd4PYgZMY7ks5vHu_mgaJpZM4aUrJr>.

[jponge]

On SSE vs SockJS: SSE is server to clients, while SockJS is bi-directional.

For the cases where the client doesn't need to push to the server SSE is a great choice, and it doesn't require any client library.

[aesteve]

iirc it was not rejected by @pmlopes , I just did not find neither the time nor the way to submit it to vertx-web, because of the reason mentioned above: I'm using the client-side implementation (EventSource) to test the server-side, and vice-versa. So splitting the implementation into two parts would lead to a cyclic dependency, which was bad.
My bad on that part, I'd have to re-write all the testing stuff if needed to split it into client/server, it's not well designed.

[vietj]

I did not say it was rejected by @pmlopes, I said that there was a discussion about supporting SSE or not in vertx-web a long time ago :-)

…

On 28 Jan 2019, at 14:08, Arnaud Esteve ***@***.***> wrote: iirc it was not rejected by @pmlopes <https://github.com/pmlopes> , I just did not find neither the time nor the way to submit it to vertx-web, because of the reason mentioned above: I'm using the client-side implementation (EventSource) to test the server-side, and vice-versa. So splitting the implementation into two parts would lead to a cyclic dependency, which was bad. My bad on that part, I'd have to re-write all the testing stuff if needed to split it into client/server, it's not well designed. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AANxikKb3bqwqD0-Bk_sM0Rr0HDPCilwks5vHvYygaJpZM4aUrJr>.

[pmlopes]

There are only two hard things in Computer Science: cache invalidation and naming things.
-- Phil Karlton

In vert.x web sockjs is used to name 2 things:

• sockjs (the protocol)
• sockjs bridge

While the sockjs protocol is bi-directional as @jponge said, the bridge allows both modes. The bridge can be configured to disable protocols, so if a user disable all but SSE, the the bridge will only work with SSE to push data, so users can use the eventbus to send data to clients in a simple way:

eb.send("adress", {...});

Now, this works BUT still forces users to use the sockjs client js script on the browser, since it requires the whole sockjs session setup and protocol negotiation.

My own opinion is that we should have 2 basic handlers in web:

• sse
• websocket

what would just do the setup + connection management and provide a simple way to send and receive messages. As these are useful for many cases, for example graphql.

From what I see in @aesteve project is that it does way more, it resembles like a bridge that even maps to eventbus, so in that case I believe that it deserves a project on its own.

[aesteve]

I started with a simple SSEHandler, then added bridge facilities afterwards.
(Sometimes you don't know from which verticle you'll be "sending data", and that's probabgly not the "web" one).
Having an official SSE handler in web would make my project easier, and lighter (and focusing on the bridge part).

I really agree it's the best direction.

You can take almost everything from https://github.com/aesteve/vertx-sse/blob/master/src/main/java/io/vertx/ext/web/handler/sse/impl/SSEHandlerImpl.java to create such a handler.

[jponge]

Fancy a PR on vertx-web?

…

On Wed, Jan 30, 2019 at 10:19 AM Arnaud Esteve ***@***.***> wrote: I started with a simple SSHandler, then added bridge facilities afterwards. (Sometimes you don't know from which verticle you'll be "sending data", and that's probabgly not the "web" one). Having an official SSE handler in web would make my project easier, and lighter (and focusing on the bridge part). I really agree it's the best direction. You can take almost everything from https://github.com/aesteve/vertx-sse/blob/master/src/main/java/io/vertx/ext/web/handler/sse/impl/SSEHandlerImpl.java to create such a handler. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#5 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABlaYculev8VPMq1iQpnEcfiJa94j4Nks5vIWOVgaJpZM4aUrJr> .

[aesteve]

Closing this discussion, as I submitted a draft implementation here as @jponge suggested.