-
Notifications
You must be signed in to change notification settings - Fork 8
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[DISCUSSION]: Server Side Events or Websockets? #45
Comments
@zakhaev26 Bro literally tagging me everywhere ☠️ |
@zakhaev26 SSE +1 |
GitHub is not for beginners |
Websockets are more resource intensive than sse, but until we recklessly open multiple connections, we should not face many issues regarding resource consumption. This may probably help. |
Found a 🔥 article on websockets impl in go |
Good find Mr. White |
Made a POC using kafka ,ws referring to the article. stuff works good |
In light of recent discussions and insights, I'm reconsidering our decision to utilize SSE over Websockets for emitting scores to clients.
During a conversation with a senior colleague, they shared their experience building a product (Hubilo Studio) using Websockets, WebRTC,and a LOT more things, - capable of scaling and handling up to 1L~ concurrent users. This has prompted me to reassess our choice.
He emphasized that Websockets currently offer the most robust solution, particularly considering the ecosystem and industry trends. He highlighted that many companies are shifting towards Websockets for real-time communication due to the comprehensive support and scalability options available and OSS tools around it
Our initial concern (as we , @majorbruteforce and @me discussed ) was scalability for the GC server if we choosed ws. If viable solutions exist for Websockets, it seems prudent to explore them further. The broader support and resources available for it compared to SSE may offer advantages in terms of implementation and future maintenance.
I propose revisiting our technology stack decision and considering the potential benefits of adopting Websockets for our real-time communication needs,as most of the work in the core sections (majorly the crud apis,are completed).
Stuffs like auto-healing, handling backpressure, message sharing between distributed servers using redis, connection retry mechanisms, and ack/nack support might align better with our requirements and facilitate smoother integration and maintenance.
Feedback and opinions on this matter are welcome for further discussion.
CC: @majorbruteforce @punitkr03 @soumil-kumar17
The text was updated successfully, but these errors were encountered: