Please consider creating a web browser service worker SignalR client example.

[rdepena]

+1

[illeb]

+1 Any news on this?

[unsafecode]

+1

[bradygaster]

Will get on this.

[gerfen]

+1 thanks!

[etaxi341]

Totally need this... Any news?

[bradygaster]

@etaxi341 no progress has been made on the sample yet, but the support exists. @anurse do you suppose there'd be any issues putting this together? any known issues trying to pair SignalR with web browser service workers we've already seen? Cursory looks at the docs on service workers - feels like a slightly different paradigm that presumes the potential for "disconnectedness." That would thwart SignalR inherently, it would seem. that said, i'd be interested in what sort of scenarios you'd like to see, @etaxi341?

[davidfowl]

We added support for this in 3.0.

[bradygaster]

i've not seen a sample for this yet, will review the docs and see if something's complete enough, unless you have a gist sitting around? :)

[davidfowl]

https://github.com/aspnet/AspNetCore/blob/9158039c9515e46d39c90f462ae91827769889c4/src/SignalR/samples/SignalRSamples/wwwroot/worker.html

https://github.com/aspnet/AspNetCore/blob/9158039c9515e46d39c90f462ae91827769889c4/src/SignalR/samples/SignalRSamples/wwwroot/worker.js

[etaxi341]

These are sadly not Service Worker examples. This is a Web Worker :/ I would just want to know if it's possible to call a push event of the service worker via SignalR, so I don't have to rewrite my whole chat system.

[davidfowl]

Service workers aren’t the place for persistent connections.

[John0King]

@davidfowl I'm also looking for solution for real time push notification, current the only worker that support one worker per browser and every browser support is ServiceWorker.

• for push notification I don't want push multiple notification if user open multiple tab .
• realtime

Service workers aren’t the place for persistent connections.

Maybe I'm wrong , but a websocket connection is only thing I know that work in real time.

[NikKomarov]

@John0King did you find any solution? I'm facing same problem. Implemented mvp using localstorage, but code is awful))))

[NikKomarov]

Made proof of concept with shared workers, hope it will be useful repo

[John0King]

@NikKomarov not yet, I notice there's a Web Push API work together with ServiceWorker, but I'm not sure it will work together with SignalR

[analogrelay]

I notice there's a Web Push API work together with ServiceWorker, but I'm not sure it will work together with SignalR

It won't by default, but this is something we've thought about. The trick with Service Workers is lifetime. A Service Worker will be shut down when there's no activity in it (i.e. it's waiting for a push notification). That's why a WebSocket isn't a great option because the WebSocket will be terminated if there is no activity on the pages attached to the Service Worker.

The Web Push API gets around this by allowing the Service Worker to register handlers for push notifications. When a push notification comes in (the browser is natively listening for this), the browser starts the Service Worker and fires the event. It would be possible for SignalR to have some kind of virtual "push notification based" transport, but we haven't done much design on that. It's an idea we've floated around though.

I'd love to hear more about the kinds of apps you're developing with Service Workers and how SignalR can help with them. We can enable WebSocket support in a Service Worker fairly easily if that will really help your scenario, but I'd like to fully understand how you plan to use Service Workers so we don't end up with features that don't really work (i.e. WebSockets that just drop connections).

[John0King]

It would be possible for SignalR to have some kind of virtual "push notification based" transport

I'm thinking maybe we need a new component/product to achieve the Push service, not only for "Web Push" , but also for Android, IOS , Windows and Android in China's Unified Push Alliance , and should also allow extend more. I think signarlR may not suitable for push , signarlR depend on an active connection, and there's no actived (direct) connection between server and the client .

[analogrelay]

signarlR depend on an active connection

I don't think that's necessarily the case. The current implementation over WebSockets depends on an active connection but we have transports like Long Polling in which there is no long-running TCP connection. Long Polling is still not appropriate in a Service Worker but it shows that we have a pattern for establishing a long-running connection over multiple short-lived requests. We achieve a virtual "persistent connection" through multiple requests and push notifications are similar to that. But this is all beyond the scope of our current planning, just some ideas we're throwing around.

[TASimpson]

hi @anurse! late to the game here. but i am currently looking for a way to integrate service workers and signalr. we currently have set up a notifications system that works great with signalr when browser is open. but i know need a way that if they close the app (but still signed in) that they get the push notification available. i know there are issues with persistent connections. but i don't want my socket to close due to service worker falling asleep.

what would be the best way to handle "waking" up service worker if signalr pushes out an event? i hope i didn't overlook the solution above...and appreciate any help :)

thanks in advance!

[analogrelay]

but i know need a way that if they close the app (but still signed in) that they get the push notification available. i know there are issues with persistent connections. but i don't want my socket to close due to service worker falling asleep.

There's no way to keep a socket open when the browser suspends the service worker. It is terminated by the browser directly. This is why SignalR isn't really a good option for service workers right now. There is a native push notifications API that does work when the worker is shut down. We've speculated on ideas to integrate SignalR with that but have no concrete ideas or plans at this time.

[TomRandles]

Any updates on this issue?

I had been looking for sample code of SignalR server running in a worker service. The goal was to decouple the backend service (continuous polling) from the web app infrastructure and run the backend service in a Windows service or a Linux daemon in future. However, it looks like my assumptions on SignalR being a genuine background service were misplaced.

Can someone clarify the following:

1. Is it the case that SignalR hub server is and will always require to be executed as an integral part of an ASP.NET server app?
2. This web app needs to keen open connections to keep SignalR connectivity alive?
3. What are the alternatives to SignalR for a backend, event-driven service to update clients with regular polling data?

[davidfowl]

Is it the case that SignalR hub server is and will always require to be executed as an integral part of an ASP.NET server app?

Yes.

This web app needs to keen open connections to keep SignalR connectivity alive?

Yes.

What are the alternatives to SignalR for a backend, event-driven service to update clients with regular polling data?

Not sure what you mean. What are your requirements for this service?

[TomRandles]

The goal is to decouple the backend service (continuous polling app) from the web app ASP.NET infrastructure and run the backend service in a Windows service or a Linux daemon.

[davidfowl]

So you have 2 things:

1. A backend service that polls the web application for updates
2. A web application that owns the state?

You want to avoid the backend polling the web application, signalr is a great alternative there. As for decoupling, what do you mean? What is backend talking to, if not the web application to get updates?

[TomRandles]

The backend polling I refer to hear is polling room sensor measurements. So the backend service does the following every minute:

1. Poll sensor measurement
2. Save result in DB
3. Notify web client of measurement (this is the SignalR function)

[davidfowl]

Perfect, so for your step 3:

Notify web client of measurement (this is the SignalR function)

Where are these clients connected?

[TomRandles]

These clients are connected from a standard ASP.NET Core web app (ObserveSensors Razor Page)

[davidfowl]

So you'd like to do this:

[ background service ] -> [ web application ] -> [ client ]

You want to send a notification from the background service to the connected clients via the web application. The service needs some way to communication with the web application, I can think of a couple of ways:

• The background service can send an HTTP request to the web application which can then use SignalR to publish the messages to connected clients.

• You can introduce a queue/bus between the background service and the web application. In this model, the web application is receiving messages and sending updates to connected clients. This could be something like a redis that sends messages to web application which can then send messages to the connected clients.

• You can configure SignalR with a backplane on the background service (like redis) and use the IHubContext to communicate over redis to talk to those clients directly.

In that last option, you basically need to reference ASP.NET Core in your background service, then wire up the SignalR redis backplane (AddSignalR().AddRedis(...)), and the same needs to be done in the web application. That should allow you to inject an IHubContext\<THub> into your worker process and directly send messages to the web application (via redis).

does that help?

[TomRandles]

Yes, this is exactly what I need. I will investigate these options. I like the idea of a message queue / bus to send these measurement updates between the back-end service and the web app server.

Thanks for the great support, much appreciated!