How do you implement internal user messaging in your app?

I don't, and I consider it a wasted effort. There are existing apps for messaging.

Unless your app is a social app, and even then I'd integrate messaging only if it's a core ability.

At work, the team that was responsible for the app before I came along, 12 years ago, wanted to integrate a messaging ability into our internal company app.

I was literally shocked when they told me that, since that it reflected such a disconnect from reality, reality being the app was extremely crashy, not documented, and filled with bugs, and a disconnect from what users really wanted (I'm a former user turned core dev) that I couldn't even believe these people were for real.

A very simple way is by having the app listen to a Firebase JSON object via a websocket. Whenever the contents (of the "chatroom") change, the new text is pushed down to all users in the room.

In fact, this was the original use case for Firebase, which was first released as a tool for building in-app chats.

What I normally do is restrict communication to sole A-Z, a-z and 0-9. And store everything locally on each persons computer with a really simple encryption method so you don't actually see the chat. This protects you from liability as well as any exploits due to not sanitizing the data.

Literally just a "GET getChatMessage(AUTH, USER)" and a "POST sendChatMessage(AUTH, USER)". And inside getChatMessage, delete all messages that are sent.

IMO the easiest path is to use a ready-made chat SDK and a hosted service.

But it only make sense if their pricing fit your business model.

Usually such services are priced by number of users and/or concurrent connections. So they only make sense when you're small and very fast can become prohibitively expensive. Then it's a time to implement your own messaging functionality.

Hi, I'm one of the founders of https://talkjs.com, a chat SDK with a pre-built UI. Obviously my position is biased.

Users have come to expect a chat experience that Just Works, and has all the basics covered. Those basics, however, go a lot longer than just the websocket/firebase "hello world" chat app and it's a lot of work to cover them sufficiently well. Typing indicators, online status, sharing photos and files and locations, reliable delivery on shitty networks, notifications through other channels (eg push, email, etc) when not logged into your site/app, URL previews, read receipts, replies, edit/delete, emoji rendering, emoji reactions, and on and on and on. And with good design and UX for all of them.

Must you have all of these? Definitely not. But if a user feels they need some of them to have a comfortable/effective chat, they'll go to great lengths to move the conversation away from your app to some other channel (eg Telegram or WhatsApp). We have quite some customers who replaced a handrolled chat by TalkJS, citing users actively trying to circumvent their own messaging functionality as a primary reason.

Meta level note: Most users, especially the not-very-techy ones (ie the vast majority) really do appreciate having good communication tools right at their fingertips, directly in the application they're currently using. Nevertheless I agree with the current top comment in that if you business does not suffer from leaking users to other services and your users are relatively tech savvy, you probably get the happiest users fastest by just letting people share Telegram/Whatsapp/Matrix/Discord contact info and calling it a day. But otherwise, build a good chat feature. We're just one of the options, it's worth it and it's very little work.

Do reach out if you think we may be of service! Our chat support is manned by programmers so ask away :-) (or hit me an email, contact info in my hn profile)

Messaging is a hugely complex with the amount of features users expect nowadays. Best to integrate an existing FOSS solution and customise it to your particular needs e.g. Matrix, XMPP, Mattermost, Rocket Chat, etc.

I know people who integrated Mattermost — after stripping away most of its features because it wasn't needed — into another web app.

Definitely not easy, and I'm not exactly sure if it's the best choice, but it's doable.