SSE vs gRPC?

[marcvanandel]

Hi @brechtvdv, thanks for your great article and research. Very interesting to read.

In the point of view of LDES and Event Sourcing, I'm wondering what the difference would have been between SSE and gRPC. I'm familliar with the AxonFramework and AxonServer which uses gRPC instead of SSE or WebSockets. I know gRPC is a whole different kind of protocol ... but still could be of relevance to this research. I'm curious if you have had a look into gRPC and whether you've considered this protocol for this research or not?

NOTE I'n not sure this is the best way to address such a question, but at least it is open and connected to the paper 😉

Regards, Marc

[marcvanandel]

See this documentation also

[brechtvdv]

Hi Marc,

Thank you for your interest in my article!

I haven't considered this protocol as I wasn't aware of its existence, but I see compatibility on two levels:

• gRPC works with SSE, so LDES clients could fetch the latest data using the native EventSource object. Mind that SSE or WebSockets should only be used for LDES synchronization if the maximum latency on the client must be below 10 seconds.
• gRPC is compatible with REST-based Web APIs . A reverse proxy is deployed on top of a gRPC service. The latter can read the event source store to create the Linked Data Fragments of the LDES. I'm not sure that you can enable HTTP caching on the proxy.

Kind regards, Brecht

[marcvanandel]

Thanks for your extensive response!

• 'gRPC works with SSE' ... is not quite true if I'm understanding the documentation well. gRPC does implement SSE similarly as the HTTP SSE spec ... but it is not the same. Nonetheless SSE as described in your article might work for HTTP as well as gRPC. I agree on that!
• As you mention the EventSource object for LDES synchronization for clients I wonder if you have any experience or examples about how to implement that properly? I've been playing with this LDES client ... but it seems the client and/or LDES spec is mostly expecting a fixed tree of events instead of an ever growing list of events. I haven't found anything (yet) on the EventSource object you mentioned for this topic. Maybe you can point me to some links or documentation?
• Caching is an interesting topic in case of an event stream. Will you ever need an event more than once? Once processed the views has been updated ... and that event is not of interest anymore, right? Of course for tracebility of provenance is it very helpful to keep a reference to that event ... but caching is at a technical level where it will probably not be used twice (in an event-sourced set up, that is) Am I missing something here? (of course for your article caching is a relevant concept, but in case of event-sourcing is it not)

Kind regards, Marc