Ask HN: What is your recommended stack for real time chat?
If you were building a new real time chat app like discord or slack in 2022, what would your tech stack look like?
I’m in this situation right now and am exploring options that will help me avoid reinventing the wheel.
My plan was to just build it from scratch using socket.io.
While looking at options like using matrix or using a third party tool like pusher, I thought to check here to see what others have done.
32 comments
[ 7.3 ms ] story [ 70.8 ms ] threadThere are more chat options here [4].
[1a] - https://www.unrealircd.org/
[1b]- https://github.com/unrealircd/unrealircd/
[2a] - https://anope.org/
[2b] - https://github.com/anope/anope/
[3a] - https://thelounge.chat/
[3b] - https://github.com/thelounge
[4] - https://www.ilmarilauhakangas.fi/irc_technology_news_from_th...
Thanks for the suggestion!
That said, the right stack is generally the one that matches your requirements, and (if this isn't primarily a learning exercise) whatever you're most familiar with. The hardest part of building a Discord or Slack-like in 2022 is actually not the technical stuff. There are many comprehensive open-source products already out there that compete with these companies, such as Mattermost, RocketChat and Element.
And I’ll have to take a look at prosody, I hadn’t heard of it but I did see a lot about XMPP in my research.
It is an nginx extension, that has supports all types of clients, channels, multiplexing, introspection, tens of thosuands connects, etc.
For a MVP, it's hard to beat Phoenix Framework channels and Liveview, and if you want to completely decouple the UI from the backend with something like a native app, or separate webapp, it's absurdly easy to just add the resources to a route that goes through the :api pipeline instead of the :browser.
Once you are ready to outgrow a single machine deployment, the BEAM clusters so well in a way that works the same on your dev machine. Also if you want to get really complicated multi-service design, Umbrella apps are leagues better than docker-compose setups that I have had on dev machines that make a 16G Macbook pro instantly put everything into swap.
Not sure I feel the same warm feelings about umbrella apps and I definitely don't think you can compare them to general-purpose container orchestration like docker-compose, but that's totally an optional part of the language.
Otherwise, yes, Elixir/BEAM is an excellent soft real-time environment for developing chat applications. If your scale goes off the charts (millions of concurrent users), you can extend with Rust for the slower operations in your critical path. See https://discord.com/blog/using-rust-to-scale-elixir-for-11-m...
As mentioned, Phoenix Channels is a great place to start and will get you very far. The other nice and unique things in Elixir & Phoenix (OTP, LiveView, etc.) are just a bonus.
My bias would be for Matrix (being project lead thereof); there is a whole new generation of client sdks (eg matrix-rust-sdk) on the horizon which are transformative - likewise massive serverside improvements like v3 sync which will provide instant login & sync (somewhat inspired by Discord). You also get e2ee, decentralisation and bridges to a bazillion other systems too.
My initial concern was that the architecture seemed at odds with what my service needs.
While I whole heartedly approve with the decentralization and E2EE approach for a general chat solution people would use like element, mine is much more niche and I need tighter control.
That being said, I haven’t dug into it enough to see how flexible it is. It would certainly save tons of effort if I could take advantage of the hard work that people no doubt smarter than me have put into this project.
https://sendbird.com/
Let me know if you want a tour! (egbert at company domain name)
I do think there is a missing or hard to find piece for privacy oriented friends and family chat (i.e. for just a few users, not a large userbase like discord). It would among other things have a super simple desktop client that doesn't confuse my mom. Maybe an IRC extension would suffice for the server side. Client side would be tkinter and super simple, no menus, no channels, no configuration options, just type and leave it running. I sometimes think of writing something like that.
Instead, I’m building a niche socialization platform which has chat as one of its core components.
You can host it, but it is very much in the beta phases as I'm working on better storage options.
This doesn't scale, or you end up wasting all your resources on things that are not important to your customers.
Use something out there, if the business grew and you had nothing more impactful to do (building features that customers actually care about), invest on infrastructure.
While it would be acceptable to also have a web interface and/or other protocols, it should need to also display the connection information (host, port, channel) for IRC, even if JavaScripts and/or CSS are disabled.