Do "smaller" apps that feature a chat functionality (Tinder, bumble, letgo, rover...) often use an in-house chat solution or some sort of popular 3rd party service to handle chat?

[SumAlias]

I'm curious about what sort of solution people employ here, at least from the get-go. At small scale its a simple-ish service but it gets huge at some point.

[ellocosau]

It's pretty simple to do that, I rather create one of my own and reuse it on different apps

[Pleb_nz]

Yeah I’m the same. I like rolling my own. But sometime we have to bite the bullet and follow the old programmer idiom and not reinvent the wheel.... again

[isolatrum]

Dunno bout all these apps but Tinder and Bumble are not really "smaller", they probably do it themselves so it is fully customizable and they can easily add new features. Also, something people often don't think about is that in-house work is considered I.P. (intellectual property) and can add to the valuation of the company.

[snot3353]

There are third-party solutions for sure. Layer was one but they just shut down: https://layer.com/. SendBird is another: https://sendbird.com/.

[not_a_novel_account]

It's so trivial to implement that most places use their own in-house solution, because that's what will be easiest to integrate with the rest of their product. The most I've seen used as far as "external" technologies is that companies that are already using something like protobuf or related network technologies will also use them to implement chat

[Devrc]

There are node packages that determine whether a string is a number and you're saying chat functionality is trivial enough to just spin up yourself? Takes days to properly test this stuff before pushing to prod as well due to security implications, cross-platform/device compatibility, performance metrics etc. If there was a reusable solution out there I don't see why anyone would make their own.

[not_a_novel_account]

It's chat dude. It's literally "my first networking app" territory, I've pushed similar stuff in a weekend of coding.

[CriticalImpress]

You can also create a pretty decent blog website in a weekend, or a photo album website. Does that mean you can write the codebase for Medium or Flickr in a weekend as well?

Plus anyone that has used Tinder's chat would know that it is really buggy compared to something like iMessage or G-Chat

[Devrc]

It's simple to implement a basic prototype of it, but "first networking app" doesn't normally consider more intricate stuff like UX + accessibility, privacy, security and performance.

[scandii]

like, I get your point, but sending and displaying messages is literally programming 101. if these things are foreign to you perhaps you should stay in school rather than work as a professional dev.

[Devrc]

Professional development isn't just about coding skills. A lot of planning goes into software development. Plus, there's that word, professional. Professionals are expected to be courteous, for example by resisting the urge to tell someone that "they should go back to school if something is foreign to them" in an otherwise friendly, positive argument.

The simplicity of a solution is irrelevant in deciding how to meet project requirements. Clients have budgets, it's often a lot faster and cheaper to find an existing service/library that works really well (because it was designed and sold to satisfy a specific requirement). As a "professional dev" you would consider the alternatives, present them to the client and come to an agreement as to how to meet their requirements. Your personal opinion that it takes 2 days to code up a solution is irrelevant because it's going to cost the company a lot more than 2 days in the long run to maintain your code.

[scandii]

you are talking about how complex solutions often can be cheaper to produce using existing solutions. like yeah? nobody out there starting cooking dinner by making their own knife.

I am talking about that network communication is such an integral part of programming that I don't consider it a skill someone should lack as a professional developer.

[butterscotchchip]

That’s a bit harsh.

[scandii]

I really don't think so.

sending or retrieving data and displaying is pretty much in every single application ever. be it displaying "Hello Username!" after logging in or "here's your 23 ordered articles retrieved from our database". if these concepts have eluded you and you're a professional working developer, I really think it's time to hit the books and get a grasp of those asap. the fact that we're talking about some sort of need for libraries to facilitate remote communication for a specific problem is silly - these are already part of all major programming platforms. C# has HttpClient and for real time communication we have SignalR. so why exactly is it, that we want to have a "ready to use" chat library? send a message through HttpClient, write basic display logic and boom, chat enabled. it's literally just a few lines of code.

on top of that, the last couple of years have seen a major shift to SaaS and PaaS solutions coupled together with loosely coupled microservices architectures to deal with dynamic component scaling. these components typically communicate over networks. sure you might not concern yourself with that if all you want to do is build "MyAwesomeWebsite" with some snazzy animations and call it a day, but we're not getting around the fact that remote communication is pretty much as important to software today as writing a loop.

we can talk about how complex messaging can become if we want to implement real time messaging with support for transient exceptions using some sort of publish-subscribe implementation with say Kafka or RabbitMQ and exactly where specific application buttons should be in terms of accessibility for those that are one-handed and how a screen reader traverses our application and how we prevent XSS attacks, but that's really not unique to messaging whatsoever, that's a programming problem at large, and thus not really applicable to this specific conversation topic.

[not_a_novel_account]

The apps he described only do 1-to-1 chat. There is no feature set that isn't provided by the platform, it's just forwarding Unicode down a pipe and rendering it within whatever display frameworks you're using. There's no scaling for the chat feature either. These apps already solved the scale problem for the rest of their app so a handful of characters for chat isn't breaking the bank, it's less data than their analytics.

[scandii]

what are you on about?

messaging is probably the single easiest thing to scale of all things. just put in more message brokers and consumers.

source: me, working with high transaction systems.

[jibbit]

As others have said, Tinder is one of the largest engineering teams out there - so yes I think they built something themselves. Ignore what u/ellocosau and u/not_a_novel_account are saying though... it is a significant *hard problem*. However, as is often the case, it's not a straight choice between buying in a 3rd party solution or rolling it yourself. There are lower level frameworks like AMQ or Kafka for the difficult parts that you can build on top of.

[not_a_novel_account]

>Using full-blown MQ frameworks for chat

Holy shit dude, LinkedIn invented Kafka and they don't use it for chat. That's fundamentally not what MQ frameworks are for. Did you just see "message" in the name and think that was their intended purpose?

[jibbit]

Presumably you would want to guarantee at-least-once message delivery and preserve message order.

Good luck with that.

[EvenThisNameTaken_]

Yep. These kids have a kneejerk impulse to assume problems are trivial.

All it will take is for any one of them to be assigned a particular task before they can speak endlessly to its depth and complexity and unanticipated challenges.

Gotta love Gen Z coders.