Question:

For a real time chat (web) app. Whats the best technology to use for this? I dont want the chats to have delays or glitches (in case it gets sent but not delivered etc).

Backend stack is java spring boot

How about kafka? Or rabbitmq? Or socket.io? Should i use redis? Should i use AWS SQS? Talking about cloud what AWS tools should i be using to handle this the best way?

Note: it must be scalable. Meaning if i wanted to extend this software more by building a mobile app (aside from web), i should be able to use the same backend easily

Note 2: it is not ONLY a chat app. Chatting is just 1 out of many functionalities. So chatting is not the main component of the project just a side thing

Keep in mind the backend is a microservice architecture etc. Database postgresql.

"I dont want the chats to have delays or glitches"

- you can't do anything about delays - if the connection is slow it's slow. and reducing glitches is not really about which technology to choose, but about how you use it.

don't think about "what can i use", but about "_how_ can i implement it?"

same about scalability. it's almost exclusively a matter of how you design your application, not what tech stack you use.

Weird rant you got here, nothing about shitting.

Well anyway, if you do decide with ExpressJS and MySQL and Redis stack, I have been building one for my portfolio. You can check my profile out.

Your rant simplifies things to a level of being a complete joke.

You cannot scale "magically".

Nor can you use the same backend for entirely different things.

Nor can one just design a chat - with the requirements you mentioned - in a short amount of time.

Let's start with a simple equation first:

Clients X Messages X Chats x Message Length.

It's bogus, but that's in a nutshell what you need to store.

Now the interesting part regarding databases is latency. Aka the killjoy / party pooper / spoil sport, the temporal aspect.

Any database will come to it's limit when it's flooded by requests, so there will be always a latency included to process the requests.

What most "large" chat platforms do is either combining multiple layers of databases, e.g. short term caches, with another layer of long term storage.

To make it scalable, garnish with a replication setup.

These architectures aren't hard to understand, but a pain in the ass to implement properly. There's a lot of knowledge required, plus a lot of fiddling.

Note that I'm talking about a chat system like Discord, RocketChat, Teams or sth. like that. RocketChat e.g. utilizes MongoDb with a replica set - when you crawl through their GitHub, you find a *lot* of performance related issues, though I must admit that they did a fine job given that they only utilize MongoDb.

https://discord.com/blog/...

Discord seems to use Cassandra. ScyllaDb would be an alternative.

Long message short: the aspect which database you choose is important. But it "pales" in comparison to how clever you utilize it and how the architecture works in general.

A database decision is like 25 % of the job. Maximizing the databases strengthes while compensating for it's weaknesses by software, iteratively improving performance and adapting the architecture long term is the 75 % that counts.

You don't just stick a database in and be done with it.

"Kafka or rabbitMq or socket.io?"

socket.io for the frontend regardless of database.

You can start building an MVP with nothing but socket.io and storing everything in json files until you figure out which dB to pick. I've done it, and kinda gave up on the project cause I didn't have any unique ideas for the frontend compared to other chat clients

@jiraTicket so what technology do i use for chatting

@IntrusionCM Amazing read..

.

@b2plane 1st u need a keyboard for that...text to speech is not yet that reliable ;p

If i would want to build a massively scalable message router (and that is what a chat server is), i would still use Erlang (or Elixir because its 2023) for that.

Feel like you need to look into things like zookeeper, out of order delivery and concepts like vector clock for things like this

@bigmonsterlover Not magically - it is still a lot of work to actually get it scalable and not break when you scale it up. But at least the language and standard library are designed with massive concurrency in mind.

Any progress on this project?

@retoor not yet i wanted to know this before building foundation