Building chat for your application? Maybe you shouldn’t…
This was my response in 2015 to a question about building chat functionality while I was Director of Engineering at Hinge. At the time we had a multi-platform chat implementation across iOS and Android with probably ~500K MAU, supported by an engineering team of about eight. The question was originally asked on the NYC CTO School Meetup forum (great group BTW) and it was about building chat for a web app. I started to publish this after encouragement from a few people on the original thread and then later having to dig it up to share again a few times. I updated the list of links at the bottom to include more time-relevant material in 2018, ie the second time I thought about publishing this. After this came up again in a random conversation in 2020 (ie the third and final time), I’m finally publishing it now just to get it over with. 😄
TL;DR:
1) IF chat is critically important to your application, but not a differentiating feature, AND
2) you expect the scale to be significantly more than a handful of concurrent users
THEN….consider buying, not building your chat implementation.
NOTE: I also think you can take the principle above and substitute “chat” with just about “any complex feature that can be offered as a commodity service”, and it would still hold true.
Below is the question that was asked in the CTO School forum…
All,
We are building a product that incorporates real time chat technology.
I was wondering what client side technologies are recommended to help it. There are a bunch out there and I am not sure if just jquery, html, css would cut it.
It would just be one on one chat with real-time notifications for new messages to the user in the form of an icon.
The back end is Rails and mysql.
Thanks.
On Mar 16, 2015, at 11:47 AM, Jonathan Vanasco wrote:
What’s the scale of this?
For Tens of simultaneous users, the backend won’t really matter.
If you’re looking at hundreds/thousands, then I’d look at using a third party service to get started OR shift my focus on Erlang… and consider scala or node.js .
The remainder of the text in this article was written in 2015, in response to the above, though it’s been lightly edited to ensure verb tenses make sense now that I’m no longer at Hinge.
So far people have suggested what libraries/languages/services you should use to build your chat implementation.
I’d like to ask you to consider if you really should be building it yourself at all.
Apologies in advance for what may be perceived as a rant, especially if you only need to pass around a few messages via javascript.
If chat is going to be a critical part of your application, but is not meant to be one of your core competencies (meaning something you do well and differentiates you from your competitors), I would suggest you avoid building it yourself, if you can help it. Especially as Jonathan Vanasco alluded to above regarding the scale (simultaneous users) of the application. The issue becomes even more complex if you’re dealing with mobile devices and not just desktop web browsers. If it’s not going to be critical to your application or the scale is reasonably small, then this decision is less important and you can stop reading the rest of the novel I’ve written below.
Teams generally want to spend the majority of their time working within their core competencies, anything outside of those will largely be a distraction for the overall priorities for the business. A truly robust chat solution is a complex system and not something that can be slapped together quickly from scratch. Anything critically important that is slapped together quickly, will likely become an ongoing distraction from your preferred priorities, as it becomes necessary to patch the holes in the initial implementation. If a critical portion of your application is not a core competency, but instead an ongoing distraction, it sounds like a recipe for a poor experience for your users and a lot of wasted cycles for your team.
At Hinge we built multiple versions of our own custom chat implementation, using varying levels of 3rd-party services for infrastructure message plumbing. Chat for us was a critical part of our application, but it wasn’t meant to be one of our core competencies (our top concern was introducing you to the best dates possible). As such, for us, our chat implementation was an ongoing distraction since the first day we rolled it out (though in 2013 when we built our first implementation, there were far fewer alternatives than there are now), until we partnered with Layer and retired most of the custom code we had written. We spent countless hours troubleshooting chat across two different platforms and as such, had to divert significant engineering time away from other projects and features to address the issues in our chat implementation. The time we spent maintaining the chat implementation with Layer was still significant, partially because of our different implementations across iOS and Android, but the result was still a much higher quality product and considerably less engineering time spent troubleshooting unreliable messages.
Using an async messaging library like Socket.io, Meteor, Faye prevents you from having to write the more complex parts of the code for message transmission, but you still have to operate the infrastructure running the code that handles message transmission, as well as write the business logic for dealing with chat participants, conversations, and the UI.
Using an async messaging service like Pusher, Firebase, PubNub prevents you from writing code for message transmission, as well as dealing with infrastructure, but still leaves you with the business logic for dealing with chat participants, conversations, and the UI. I’d also strongly recommend against believing that the reference chat apps these folks provide will meet your use case; we used one of them, and I won’t say which, but the result was still terrible, even after HOURS on the phone with their VP of Engineering who helped improve the design of the implementation. (⚠️ sidenote: this was originally written in 2015, and perhaps the reference chat apps have improved, but before using any of them I’d ask them for details and a customer reference from the largest customer they have using the reference implementation in production)
Business logic for chat participants, conversations, and UI may sound like small potatoes, but there’s still a lot of complexity if you have deal with things like:
- security/access control
- message syncing, intelligent retry for sending/delivery, detecting duplicates messages
- multi-device support
- cross-platform support
- push notifications
- users blocking other users
- rich message content (e.g. hyperlinks for urls, email addresses, phone numbers, emojis, images, etc)
- typing indicators
- read receipts
- presence indicators
- offline message viewing/composition
- etc…..
Soooo, if chat is going to be critical to your application and the scale is larger than a handful of users, BUT not a core competency, then I’d recommend considering a 3rd-party service that does as much for you as possible. Something like one of these services:
- Quickblox
- ̶L̶a̶y̶e̶r̶ (it’s now 2020 and Layer is out of business 😢)
- Applozic
- SendBird
- Contus Fly
If you want to make a really serious investment in building your own chat application take a look at these articles, the MQTT protocol is supposed to be pretty sweet. Below are some links about it.
- Facebook blog post about building Messenger using MQTT
- Slideshare about Low Latency Mobile Messaging using MQTT
- Quora article on why FB didn’t use XMPP
Best of luck,
AJ
Addendum
At a certain scale, it makes sense from both a cost and flexibility standpoint to build and support the underlying chat architecture yourself. The original response was written for the typical startup scenario where “my XYZ app now needs chat and I think I can whip something up pretty quick”.
The bulk of this was written t̶h̶r̶e̶e̶, okay five, years ago and thus s̶o̶m̶e̶ many of the technologies/companies mentioned are probably no longer the most relevant options available, however, I think the gist still applies.
Here’s the original message if you’re interested, but unfortunately Meetup doesn’t seem to offer threads so the full context will be missing.