Easiest Chat-as-a-Service

Use case

I am interested to build a marketplace PWA (progressive web app). I want to use chat as a service.

Tech stack

• Devops: AWS
• Backend: Django
• Database: PostgreSQL
• Frontend: Undecided, but keeping it as basic as possible

Top features

I am looking for in chat as a service:

• Security
  • Only the root user has access to unencrypted messages
  • Service provider shouldn't be able to read them
• Data ownership
  • As a data-driven guy, I will like to own the data, and not the service provider
• Ease of usage
  • Write feature-packed chat with as little code as possible
• Ease of integration
  • SSO (Single Sign on); Able to authenticate and authorize users
• Independent of programming framework / language
  • Since I might change my backend depending on needs

Not sure if there's any software in the market that does it all.

What I have in mind: a code snippet like Google Analytics, where all I need to do is to paste it in my PWA.

Possible software

• SendBird

✔️ 1st Google result
✔️ Seems easy to use

• Twilio Programmable Chat

✔️ Seems like a very good option as I might need other Twilio services

• AWS AppSync

✔️ I will assume AWS can scale indefinitely and cheaper than the rest for the services provided
✔️ Integrates well with other AWS services
❌ Seems like lots of coding is required

• Stream

❌ Limited SDK; Only React, iOS & Java

See below: https://dev.to/tschellenbach/comment/mm04

I have not tested any of them and wish to hear your experience. Thanks!

Comments

[Thierry]

Hi Shawn, funny that I'm reading this. Don't get questions about Stream on dev.to all that often. Also, welcome to dev.to I see that this is your first question.

What made you think Stream only has React, iOS & Java SDKs?
We power chat and activity feeds for over 500 million end-users. Pretty much support any backend or frontend integration. The react tutorial is a good starting point: getstream.io/chat/react-chat/tutor... Python SDK is available here: github.com/getstream/stream-chat-p...

There are many possible solutions for building chat. In my experience only Sendbird and Stream allow you to launch chat quickly and build a polished user experience. A quick comparison:

• For React, RN, Flutter, iOS & Android Stream offers both an SDK as well as UI/UX components. IE in React you have a ChannelList component, and a MessageList etc. This helps speed up the integration quite a bit.
• In general, I would recommend using React for your frontend stack. Nowadays with Hooks it's pretty awesome what you can build and it's much easier to test and keep bug free than a vanilla HTML/JS approach
• Stream has reactions, threads, read state and rich URL previews
• Sendbird has integrated translations (with Stream you need to build this yourself by connecting together APIs)
• Sendbird supports Xamarin
• Stream's underlying tech is based on Go, RocksDB & Raft -> end result is better uptime and performance compared to Sendbird
• Sendbird is usually 2x the price point of Stream (of course still very affordable compared to in-house, depends a bit on which region you're hiring devs, but usually true)

There are other chat solutions out there besides Stream and Sendbird, but we see many customers switch from those solutions to Stream. So I guess that says something.

[Thierry]

PS on the security side of things, you might enjoy this blogpost virgilsecurity.com/end-to-end-encr...

[Shawn Ng]

@Thierry

It takes me 5 seconds to see what SDKs are available here, it clearly states (React, iOS & Java): getstream.io/chat/docs/?language=js

And you can sell Stream better to me if you answer my questions directly. I think you missed out what I asked, I will paste them here:

• PWA (progressive web app)
• Frontend: Undecided, but keeping it as basic as possible

1. Security
   • Only the root user has access to unencrypted messages
   • Service provider shouldn't be able to read them
2. Data ownership
   • As a data-driven guy, I will like to own the data, and not the service provider
3. Ease of usage
   • Write feature-packed chat with as little code as possible
4. Ease of integration
   • SSO (Single Sign on); Able to authenticate and authorize users
5. Independent of programming framework / language
   • Since I might change my backend depending on needs

Perhaps you have the answers inside the documentation. But I would prefer short and direct answer here.

I am here for answers, not debates. Thanks!

[Thierry]

I do see how it can be confusing that we don't list our other SDKs there. That list only shows the frontend integrations. Here are all the SDKs: JS, Ruby, Python, Java, PHP, Go, PHP, .NET, Swift, Kotlin, Dart.

1. You can build e2e encrypted chat by combining Virgil (or your own encryption setup) with Stream. Note that this breaks the built-in AI moderation capabilities.
2. True for all major players in this space. Definitely Twilio, Stream, Sendbird. We don't do anything with your data
3. Ease of use depends on the frontend SDK you end up using. I recommend React
4. Both Sendbird and Stream support this. Stream also has a configurable permissions system so you can allow moderators to do more things than regular users.
5. Xamarin is supported only by Sendbird, Flutter by Stream. Everything else reasonably mainstream is supported by both.

[Shawn Ng]

@Thierry

Thanks for the response. I have corrected my original post.

[Shawn Ng]

@Thierry

As a data guy, I'm very interested to see the numbers if available 😁

There are other chat solutions out there besides Stream and Sendbird, but we see many customers switch from those solutions to Stream. So I guess that says something.

[Pyry Takala]

@shawnngtq what service did you end up picking and how were your experiences? I'm building a chat to a social site and trying to pick between getstream.io, sendbird, twilio, cometchat

[Shawn Ng]

@pyrytakala , I haven't try either of them as I decided to focus on a different project first. If you are indeed building a chat, I would love to hear from you instead :)

[Pyry Takala]

Sure. I ended up using Stream, as they announced a free offering for makers. The experience has been decent, though they could definitely improve on their documentation sometimes.

[John S. Kim 💬]

Thanks for recognizing us Shawn! :) Appreciate it!