In our application we have a request to dataservices which itself calls a 3rd party rest api. This operation is implemented in spring mvc controller with async servlet processing capabilities and not a dataservices rpc operation.
Depending on the document that is being processed by dataservices the processing may take more than a minute. This causes a timeout for the browser so we would like to avoid it. I am investigating different options at this point.
One option is to use Server Sent Events to keep the connection from timing out. Since we are already using servlet async processing capabilities in data-services adding support for server send events is relatively easy there.
However I’m struggling to find a way to make use on client side for this. I know that @microsoft/fetch-event-source is able to process these server sent events.
But how can I integrate @microsoft/fetch-event-source with RestServerConnector of a12 client to make use of the request processing chain for auth for example?
Hi @andreas-fresh-mesa,
I remember i did some support for projects that implemented server-sent events in the past but usually they did not make use of the @microsoft/fetch-event-source package, as far as i know they used the eventsource package (i guess in fact same same).
The main point I see is that the most simple solution for you would be to just add the authentication header to your dedicated fetchEventSource implementation and do not stick to the (Rest-)ServerConnector at all for this.
If i overlooked something here feel free to tell me.
From level of integrate @microsoft/fetch-event-source with RestServerConnector i can only think of either monkey patching (or proxying) the global fetch (with having a flag that indicates fetch target sse) when doing the SSE request (then just shift the headers to a dedicated sse request) and return an empty resolve promise and try to manage the whole sse live cycle in that.
So i am interested in, are you relying on adding the behaviour to existing default server connector or is it only about re-usage of existing header filters (then probably Auth header is enough - you could possibly also utilize UaaFilters.AuthorizationHeaderFilter for that)
I did use monkeypatching to allow reusing the complete filter chain the already configured rest server connector provides. This did work in some first tests. However since we currently have another workaround for the original problem in place I tried to solve with using server sent events I stopped looking further into this.