I've spent the last year working on an e-commerce project that esclusively uses websocket for real-time updates and communication. There are some great benefits to it, but websockets also introduce a lot of technical challenges that may not be obvious when you start. Things that come to mind are:<p>- Persistent connections make horizontal scaling more difficult<p>- Web Application Firewall don't usually support payload scanning for threats over websocket messages (eg. Cloudflare)<p>- If you need to integrate with third parties, you may end up needing a standard REST API anyway, since it's a lot less common to integrate via websockets (especially server-side). You then end up with two APIs. Also, websockets have less standard tooling for automatic documentation purposes such as Swagger/OpenAPI<p>- It's harder to load test the system, difficult to estimate the breaking point of the infrastructure via websockets<p>- HTTP Status Codes provide a standard error mechanism to HTTP server calls, while with websockets it's entirely up to you (which can be a good and bad thing)<p>- You need to manage explicitly situations where the connection drops and what to do when it recovers, as you may have lost some data in the meantime<p>- You give up a lot of standard mature tooling for caching and rate limiting
There is a concerning cargo cult feedback loop in the industry fueled by companies offering websocket based solutions and writing long articles about everything that this COULD be used for and young developers half heartedly looking for solutions and then defaulting to websockets for anything with some server push or realtime requirements. Websockets are bad advice for sending tennis-match data and reddit-comment counters to a client, websockets are bad advice for messenger/ chat applications and most other things used as an example. They are mostly useful for things where high frequency bi-directional communication is required such as syncing multiple cursors, player positions/actions in realtime games and visual co-editing such as figma. (every 5+ seconds is not high frequency) If you are not building one of those chances are high you are being lured into that cargo cult. All you need is http2 and SSE or streaming fetch. Websocket companies will tell you all about how most problems are solved by their offerings or fancy frameworks but ignore the fact those problems could be not there in the first place. And also inexperienced developers that never operated websocket based solutions over a few years or millions of users will be very quick to lecture you about how they never had any problems or headaches, because its hard to admit that you skipped proper solutions research.
I'm the author of this article and would appreciate any feedback/thoughts. I included just a few examples on the graphic (mostly from memory as I was lucky enough to come of age in 1990 so lived through it).<p>I remember when Yahoo mail came along with AJAX and how astonishing it was to not have to refresh to get new mail. Although, over a dial up connection, I'm not sure how "realtime" anything was :)
If you're interested in building realtime web apps with Postgres and React, check out <a href="https://thin.dev/" rel="nofollow">https://thin.dev/</a><p>Next to great user experience, building your application in a realtime way also allows to simplify the state management in certain parts.<p>A typical react app might use something like redux to store a subset of the application's database state locally. Now whenever you do any write operations to your data, you need to make an API call and also make sure the local redux state is kept in sync.<p>When you're embracing realtime everywhere, you avoid this, because any write operation automatically updates your realtime data, so you don't need to manually e.g. update your redux state. This allows you to skip a lot of the code that's needed for state management locally, so it saves a lot time and bugs (less code => less bugs).
You should check out RxDB. It applies realtime replication to an offline first storage. This means you even have less backend load compared to regular CRUD apps. Also you get multi-tab support for free where only one browser tabs runs the client-server connection.<p><a href="https://rxdb.info/" rel="nofollow">https://rxdb.info/</a>
I wrote a very similar series of articles in 2012. <a href="https://www.computerworld.com/article/2502243/the-next-evolution-of-the-internet--the-shared-web.html" rel="nofollow">https://www.computerworld.com/article/2502243/the-next-evolu...</a><p>The timing feels a LOT better these days.
In general I don't use a websocket unless there is a "live" component, like a news ticker, or feed. I don't use React unless I am billing hourly.