4 ms·
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
by lvice 4y ago
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:
- Persistent connections make horizontal scaling more difficult
- Web Application Firewall don't usually support payload scanning for threats over websocket messages (eg. Cloudflare)
- 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
- It's harder to load test the system, difficult to estimate the breaking point of the infrastructure via websockets
- 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)
- 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
- You give up a lot of standard mature tooling for caching and rate limiting
- julianlam 4y agoThe need to support third parties is exactly why we ended up embarking on a phased deprecation of our websocket implementation. As it turned out barely anybody wanted to learn how to open a websocket connection and relearn all the oddities of a bespoke websocket connection (error handling, etc.) whereas with REST all these things are just more or less standardized.
- deleted 4y ago[deleted]
- bullen 4y agoAll problems are solved by running comet-stream on a shared parallel capable app server. That can do peak many-to-many so whatever usercase you need it will support it. Never learn things that aren't final.
- eastbayjake 4y agoIt's an interesting solution - could you elaborate more on the benefits, or even on the impetus to use websockets in an e-commerce project?
- lvice 4y agoWe use an approach similar to what's described here: https://blexin.com/en/blog-en/build-scalable-and-resilient-applications-with-akka-actors/ https://blexin.com/en/blog-en/build-scalable-and-resilient-a... Using the Actor Model provided by Akka and an event sourced architecture does not fit very well with the request-response model of HTTP. Commands are usually issued in a fire-and-forget pattern, with resulting events being pushed to the client in a completely asynchronous way. By using websockets via SignalR, we can better accomodate this pattern on the client code as well. On top of being a better fit with our backend architecture, it also provides some benefits in the frontend such as: - Limited availability items disappear as soon as they actually are not available anymore, without the client having to refresh - We can integrate more easily with payment gateways where payment confirmation usually arrives via a server side webhook. We can then easily push the "payment succeeeded" event to the client as soon as we receive it, without polling. - Even the backoffice benefits from real-time, as all backoffice users are guaranteed that when they look up a customer/orders/products, they are looking at the most up-to-date information, even if somebody else edits the same record at the same time, or the record is updated by external APIs/scheduled job. - We can provide easily real-time dashboboards that are listening to the feed of events being persisted