Hacker News new | past | comments | ask | show | jobs | submit login

Author here.

Having done this, I don't think I'd reduce it to "just a little bit of work" to make it hum in production.

Everything in between your UI components and the database layer needs to be reworked to work in the connection-oriented (Websockets) model of the world vs request-oriented world.






> Everything in between your UI components and the database layer needs to be reworked to work in the connection-oriented (Websockets) model of the world vs request-oriented world.

How so? As a minimal change, the thing on the server end of the websocket could just do the polling of your database on its own while the connection is open (using authorization credentials supplied as the websocket is being opened). If the connection dies, stop polling. This has the nice property that you're in full control of the refresh rate, can implement coordinated backoffs if the database is overloaded, etc.


Yes, but that's one part of it though. For example, you have to:

- change how you hydrate the initial state in the web component. - rework any request-oriented configurations you do at the edge based on the payloads. (For example, if you use cloudflare and use their HTTP rules, you have to rework that)


It's a good pattern to have a vanilla js network manager / layer in fe for this exact reason - makes swapping network technologies a lot simpler.

Only that knows url for endpoints, protocols and connections - and proxies between them and your app / components




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: