-3

I'm building a website where I want to allow users to subscribe to various realtime data streams. They will subscribe to few streams and it will be pushing the data back as long as they are connected. The question is, which technology is more suitable for this: Server Send Evenets, Websockets, HTTP/2, Comet? What should I use for achieving the best results? I aim for quite big amount of users with this. Will appreciate for answers pointing me in the best direction here.

orzel
  • 176
  • 2
  • 9

1 Answers1

0

This was already discussed before both when debating the role of AJAX (great for CRUD, not so much when polling) and when comparing Websocket performance vs. AJAX performance (Websockets are always faster where live updates are concerned).

Comet and SSE are interesting flavors for HTTP polling, but is the end they only mitigate the side effects to a degree, while Websockets (often coupled with the publish–subscribe pattern using Redis or something similar) are the best tool for the job.

Myst
  • 18,516
  • 2
  • 45
  • 67
  • I were in the process of writing my own backend in Go for handling data streaming. Would probably reinvent the wheel without your redis suggestion which I missed somehow (I've been reading about redis lately). Thanks a lot. – orzel Feb 09 '18 at 02:33
  • @orzel , I'm happy I could help :-) – Myst Feb 09 '18 at 02:42
  • I assume I can ommit batching with WS low overhead? – orzel Feb 09 '18 at 03:48
  • @orzel it's possible to ommit batching, but (depending on your application logic), batching can improve TCP/IP packaging and bandwidth by minimizing the TCP/IP overhead, so it's still a good idea... on the other hand, I sometimes avoid batching in favor of modular code and separation of concern - especially when I use scripting languages that allow me to forward the pub/sub directly to the client (skipping the scripting layer). It's your call, really. – Myst Feb 09 '18 at 04:51