should i use socket io to handle my app chat events
I am building a chat app kinda of a discord clone using socket io i am thinking a lot about creating global listener using socket io for things like notifications , friend requests , users connection status or anything that should be handled in real time i have noticed in discord that when any of these events happen they happen in real time and quite fast actually for example if a friend connects to the app you immediately see the friend connection status change from offline to online , when a user sends a friend request you immediately recieve a notification same if you accept the friend request your friends list updates at once or should i opt for a request - response model for example if a friend request is sent to a user i should send a request to my backend to handle that then get a response and update the new state of the app ?
6 Replies
You don’t have to choose between “only ws” or “only HTTP”
it's not a "only ws " or "only http" it's what's best for my use case which i don't know that's why i am asking
If this is a side project or very early stage startup where you're still prototyping/experimenting, I'd suggest use polling and make your backend 100% serverless (and no peer-to-peer connections either).
Latency and cost won't be optimal, but just getting the client to keep polling for updates every 500ms or something is the easiest thing to get working and deployed ASAP
You can try write the code in a way where all the updating/refreshing happens behind an interface that can be easily swapped out for something more sophisticated later on.
Optimistic updates on the client when you create a message will help a lot too!
But I reckon at first, to validate that the app is good just do nothing other than serverless HTTP requests and focus on the other parts of the app!
it's a portfolio project i do want this to be a real world app .
if your goal is to make money/make something fast wat X4 says is facts.
if you want something a tad more complex and a good execise, just build the whole app in next or something deploy on vercel and create a seperate node js application that you containerize and deploy on fly.io just for the web socket stuff
it's a portfolio project i do want this to be a real world app .If your goal is to learn for the sake of learning and, just for the fun of it, you want to try make the latency as absolutely minimal as possible - then websockets or webRTC might be worth exploring. If your goal is to make a cool thing which people enjoy using, and which looks impressive when you show it off to others - starting off by sending all your messages over HTTP is almost definitely the right call. For users located in the same continent as your server, the difference between a message taking 300ms to be received versus 3ms will not be that important. For a voice call, or a real time video game, the delay might be noticeable. But in terms of how long it takes for someone to get notified about a new friend request or a new image shared with the group chat, the user impact of an "optimal" BE setup will be very subtle and might distract you from working on more impactful parts of the project. If you haven't built a real time "multiplayer" app before, there's still going to be heaps to learn and lots of challenge even doing it the easy way with serverless backend. You'll still need to do lots of latency optimisation with stuff like optimistic updates on the client, reconciling client state and server state (e.g. ensuring everyone in a chat eventually sees all messages being in the same order), storing images/videos in the cloud and serving them efficiently. Doing things with websockets, (or even peer-to-peer if you want absolute minimal latency) can always be added in later - and you can try to architect the FE to make this easier. But it's almost certianly a mistake to set it up first before you've already done all the other more important stuff (like already made a delightful UX and implemented heaps of cool features and you've already got your friends using it and enjoying it) Something to consider - 120 words per minute is considered an extremely fast typing speed. 120wpm is 2 words per second - meaning typing out a 10 word chat message takes a very fast typer 5000 milliseconds! And this assumes continuous typing (no delay in having to read other messages or think about what they want to say) If it's taking people that long to compose their messages in the first place, the value of shaving off just a couple 100s of milliseconds is not that significant compared to the massive amount of extra complexity it'll introduce to your version 1.0. Communicating over text can still feel very real time even with a 300 millisecond delay!