socket.io with ssr

[matheusdavidson]

Does universal work with socket.io? and how to?

[Toxicable]

This is sort of a tricky question.
Universal can work with socket.io but you have to use it a in a different way.
By default Universal waits for all async operations to complete before rendering to a string, this includes things like http requests, promises, Observables and WebSockets.
Since Web Sockets are long lived they stay open and will actually block the app from rendering on Universal so you need to somehow close this connection so that Universal can render.

Sorry I can't provide specifics on how to do this since i've never used socket.io

[CaerusKaru]

By default Universal waits for all async operations to complete before rendering to a string

To follow-up on this comment, renderModuleFactory, the main action in Universal rendering, will wait for the first stable VM tick to emit before rendering. This may or may not include the WebSocket activity from socket.io. As such, the main concern should be whether or not socket.io prevents that tick from completing or not. It's possible that with WebSockets, which are just event producer/consumers, they will just be passively considered like DOM event listeners. Please feel free to test this and report back!

@matheusdavidson socket.io should work assuming the client you're using is Universal compatible (i.e. doesn't try to reference document, or window) and pulls in its own version of WebSocket for Node (I know this is an issue with Apollo atm, but socket.io I think is fine). The only issues you may face come with duplicate requests, since TransferStateHttpModule does not work with wss connections, which may result in flicker (and you will also need to provide full URLs). You can of course disable socket.io on the server by only including it in a browser-specific module or by placing socket calls behind isPlatformBrowser checks.

[Toxicable]

@CaerusKaru This here
https://github.com/angular/angular/blob/d2707f14574bdfd4ea0c0ecf3d85383f6d54186a/packages/platform-server/src/utils.ts#L46
Which means it waits for all Zones caught operations, which should be all async operations

[CaerusKaru]

After throwing together a basic WebSocket example, which socket.io will use if available, it looks like WebSockets are tracked by Zones. Here's the example on StackBlitz, running the WebSocket echo test and then closing the socket. I also updated the appRef subscribe to match what renderModuleFactory does. You can see that it is initially shown as stable, and then no other stability checks are rendered, implying that once you invoke a WebSocket, your application is unstable for the duration of its existence. See comment below for resolution.

[Toxicable]

@CaerusKaru WebSockets are tracked be Zones, you can see that by putting NgZone.assertInAngularZone() inside the handler event. Also you can see the patch here
https://github.com/angular/zone.js/blob/a66595af18d4c42584401dd2df387b02cb01d8d9/lib/browser/websocket.ts

However as I mentioned above, WebSockets are long lived, they stay open untill they are closed. In your example the WebSocket is never closed, that's why you don't see the stable event fire and why Universal wont work with socket.io or firebase without special handling for the websockets

[CaerusKaru]

@Toxicable on line 25 the socket is closed once the message is received. I saw that code too and this leads me to believe that closing the socket is not sufficient to restoring stability.

After looking into this a little more, this is apparently a documented and long-lived issue. However, I think the one advantage Universal has in this case is that I think it's almost guaranteed this won't hold up rendering, since the appRef call is almost immediately invoked after the components render (ie the initial view is stable, and then immediately not stable). But if this turns out not to be the case after testing, the recommendation would be (1) move socket.io into the browser build only or (2) run all socket.io-related code outside the Angular Zone, which may result in a performance hit/change-detection issues.

[Toxicable]

@CaerusKaru Whops, sorry missed that line, in that case I don't know whats going on in that example.

While both of those could be a solution, I personally think comming up with another way / api for handling when to render on the server should be investigated.

[CaerusKaru]

@Toxicable I think that's a great idea! Some consistency would be a relief. Do you want to open a new issue to track the feature? I have some preliminary ideas that should probably go there.

[Toxicable]

@CaerusKaru sure, but open it up on the angular repo since that's where this stems from

[CaerusKaru]

Tracking here: angular/angular#20520

[matheusdavidson]

I did try but ended up using socket only in the browser build because as you guys pointed out angular doesn't finish rendering the page, probably its waiting for a response from the socket event.

Not sure if closing the connection all the time i receive a response would be very good because we could have other code waiting for socket events.

Maybe an option would be using socket.io with promises, i will try this when i have some time.

[vikerman]

Hi - You can make a task trackable by Zone.js by doing something similar to here

https://github.com/angular/angular/blob/14e8e880222431eeccdacac6540574b49903bd79/packages/platform-server/src/http.ts#L38

Would that satisfy your use case?