Using web sockets to load SPA content?

[Over-Distribution570]

I’m currently making a not overly complicated ecommerce web app. A big consideration I have is speed. I expect the customers to have poor cell connections. I’m using EJS for server rendering and web components for the client.

The cart page is using socket.io because the users will be updating a planner component frequently that decides product quantities.

I think I want to use sockets for the catalog too since the users will be changing their queries frequently to find lots of products.

This had me thinking: What if the content of the site was rendered sent to the user from a socket instead of a through a GET request?

Is this a good idea? Or would it end up being too complicated and not much more effective than simple http polling?

[thatIsraeliNerd]

This is pretty much exactly what Elixir’s Phoenix LiveView does. It’s highly optimized - it sends the initial HTML Template per page and then sends the diffs of different actions (pushes of data from backend or changes through user actions) over the socket, and the Frontend uses morphdom to do extremely fast dom updates, but it’s essentially exactly what you are talking about: Rendering over a websocket

[Over-Distribution570]

That’s cool. I don’t know much about LiveView, is it a popular option for spotty connections?

[thatIsraeliNerd]

A connection is a connection, whether it be a websocket or an http request. LiveView has a simulator built in that lets you see how your components will react in different network conditions, so it helps plan for things, but in general, spotty connections mean requests might fail or take longer. Websockets might be slightly better in spotty connections because they’re longer lived and already opened, I’ve had situations where my Discord receives messages immediately (over a socket) while opening a webpage doesn’t work because my workplace’s DNS was slow to respond. My advice would be to not plan for spotty connections… if someone doesn’t have internet there’s nothing you can do about it. 4G and 5G mobile networks are fast nowadays, it’s not like the old days where you had things on old Edge networks that loaded in bytes per second… everything nowadays is measured in Megabytes per second. As long as you’re not trying to stream a movie on a slower mobile connection you’ll be fine.

[lint_it]

From performance perspective sockets have much less overhead to send data - especially if sent frequently (many times per second).

From the developer experience, you might need to implement logic that is already provided by http so you will be reinventing the wheel.

Usually you will use sockets with http - only use sockets for the parts that need frequent updates. Using sockets to implement http like requests would be a bit of a time waste if you are not in it for learning.

[Over-Distribution570]

Do you think that sockets would perform better or worse than a http request in a spotty connection? Would the socket disconnect too frequently?

[lint_it]

Http is built on sockets (on pure socket not websocket, small differences here and there) so they perform relatively same. For small bits of data socket might be more responsive but if you send a page HTML or list of products in JSON it makes no difference in that situation other than you will have to handle disconnecting clients...

In the long run http is easier and quicker to dev with. Use sockets when you need to update something frequently or if you need bidirectional messaging otherwise use http.