Socket.io VS Centrifugo

The purpose of Asynction is to empower a specification first approach when developing SocketIO APIs in Python. It guarantees that your API will work in accordance with its documentation.

socket.io is probably a good first step into this as it's very straightforward to use and will introduce you to principles that you can use for more complicated things going forward 💪

However, being AWS, WebSocket implementation is the bare minimum, no retry, no resume, not compatible with socket.io JS framework you must use raw WebSocket API in JS and building own wrapper would take several weeks so I've looked at alternatives like Ably.

Basically I am working on the project where we need to built the chat application for the client in MERN stack. I am familiar with the MERN stack, and worked on multiple projects and React.js in general is the technology that I am working on for almost 2 years now. I now about Socket.io and watched a few courses on "how to build the chat app using socket.io and React.js".

Check out socket.io. Depending on where you are in your journey, it might be a little tricky, or it might be not too bad.

The forked process can send messages back to the parent process so you will still have access to the array and the socket.io instance. For example, API request finishes in the forked process then it sends a message to its parent and the parent handles the message accordingly.

I wanted to make a connection on the socket.io so I used python-socket.io in the backend (FastAPI) and socket.io-client for the frontend(React.js) but I have been getting connection failed error (403 Forbidden).

i dont know how to fix it, i set the port by: const io = require('socket.io')(3000), any ideas? i think i might have to set the port a different way in order to work on heroku

And I do recommend using socket.io over raw websockets handling. Way more handy frontend and backend side.

Every time I read criticism of WebSockets it reminds me about WebSuckets (https://speakerdeck.com/3rdeden/websuckets) presentation :)

I am the author of Centrifugo server (https://github.com/centrifugal/centrifugo) - where the main protocol is WebSocket. Agree with many points in post – and if there is a chance to build sth without replacing stateless HTTP to persistent WebSocket (or EventSource, HTTP-streaming, raw TCP etc) – then definitely better to go without persistent connections.

But there are many tasks where WebSockets simply shine – by providing a better UX, providing a more interactive content, instant information/feedback. This is important to keep - even if underlying stack is complicated enough. Not every system need to scale to many machines (ex. multiplayer games with limited number of players), corporate apps not really struggle from massive reconnect scenarios, and so on. So WebSockets are definitely fine for certain scenarios IMO.

I described some problems with WebSockets Centrifugo solves in this blog post - https://centrifugal.dev/blog/2020/11/12/scaling-websocket. I don't want to say there are no problems, I want to say that WebSockets are fine in general and we can do some things to deal with things mentioned in the OP's post.

Install Centrifugo - https://github.com/centrifugal/centrifugo

We had a Django-based backend when building an intranet site for a pretty big company (~4k employees) and used https://github.com/centrifugal/centrifugo for delivering real-time updates to users. We had chat widgets, live counters, live comment system, also several corporate multiplayer games based on it. I think it's much more simple to understand and integrate with than Django Channels, more transports supported and scales better. So maybe give it a chance if you are not happy with Channels.

Using Goreleaser for https://github.com/centrifugal/centrifugo, amazing project – many thanks for it. It allowed us to quickly integrate multi-arch Docker builds recently. There was once a problem where we got faced with backwards compatibility issue during release workflow caused by some deprecation stuff removed from Goreleaser - but that was our mistake to not use a tagged version.

For those who looking into Laravel WebSockets replacement give a chance to https://github.com/centrifugal/centrifugo - it proved to help a lot dealing with WebSocket connections to backends built in languages without native/performant concurrency support. So you can continue writing business logic in Laravel, but let Centrifugo deal with persistent connection management and issue real-time updates over API.