We want to provide a chat solution so vendors and customers can communicate. The chat needs to support text and images.
Should we build or buy? From a technical point of it doesn't seem hard to implement, and the existing SaaS solutions are expensive for a multi-tenant, white-label solution.
Am I missing something?
[0] https://garnet.center
Doing this with serverless might be a lot easier than building the global network & edge infra on your own.
But a real version would need to add a lot more, like auth, rotations (who on the merchant side is supposed to answer), status tracking, image management, linking to tickets and emails, etc.
It's a lot of work. But it also sounds like it'll be core functionality for you guys, an integral part of a multi tenant B2C platform. Maybe you can start with a vendor solution for a few months, gauge reactions from both the merchants and their customers, and use that to inform whether to build your own (and what features to add, if so?)
Front end is not an issue, we need reliability and performance. Using Cloudflare D2 is also appealing.
Just anecdotal though. I have no data to back this up and this isn't my area of expertise. Good luck!
You don't need a global network and edge for a basic b2c chat. Yes it makes a difference in UX when everyone has to exchange messages through your servers in us-east instead of something closer, but the difference is so small it hardly matters unless you're being compared against a messenger that's highly focused on message latency, most are not.
It's just another facet of the on premise vs cloud discussion, really. But having a single VM handle global multi tenant chat seems like a good way to ensure headaches later on, when it's harder to change things already in prod with existing customers...
It was honestly not that hard to code, maybe 4-5k loc including all the type definitions. Took around two weeks to make after spending a week or two learning and doing PoCs. It ran on a dedicated instance and can handle like 500k concurrent conversations.
Did you choose go for its coroutine or because it’s your stack language ?
Imagine for instance a web based chat program: if you were just using ordinary web requests (not websockets) the front end would have to poll the back end periodically and you can pick your polling rate to trade off wasted polls vs latency to receive polls. I can picture making a chat app based on polling that stores the conversation in (say) PostgreSQL, but would be awkward. (At launch Twitter was built like this but it wasn't long before the system was crumbling from the load)
A chat app that uses websockets on the other hand could transmit messages almost instantly without any wasteful polling. However you are getting into the systems programming area instead of applications programming. If I were going to do it I'd consider (1) Java with threads, (2) Erlang/Elixir, or (3) Python with asyncio. Either way there would be some shared data structure in RAM about which messages get forwarded to who and it is important that it can't be screwed up by multiple users updating it.
Personally it's something I'd do for fun for learning but it's in another class than the routine work that most webdevs (including myself) do. So I am not surprised that the open source choices look thin and the commercial products are expensive.
We are not expecting a huge traffic as we launch, if the heap size is an issue we can always buy a bigger for now.
When the cost are exceeding $200/month, it will probably be a better solution indeed to change the technology to be memory efficient and async.
All major langs already have good support async/await, and where is not requirement to rewire your brain to use it. Also, you don't have to write a lot of lines to dealing with websockets, just take lib which build on top of websockets.
Anyway. If you need chat with simple feature set (1 to 1, text, imgs), then, as mentioned below, it is not hard to write it in just two weeks max. Otherwise, for chat with some specific feature set, it is actually better to buy one.
That's, say, $10-20k, as a low bar, but in truth, testing and refinement will take months, and those engineers need to stay, driving the cost up in the high 100Ks. Whereas I'm sure the vendors would be happy to bill you 1-10k/mo for a service like this and it's ready to go TODAY so you don't spend the opportunity cost.
Most of the work is really on the front end. How do you handle live messages coming in? Does it show fresh, making it jump to the bottom of the screen. UI for multiple images and files. Eventually we added a contractor to handle chat.
I'd say buy.
Or you can go for a full service like getstream.io or cometchat.com
The latter, I have found to require a lot upfront and have their own ways to do things. It's not bad if you are okay with it.
They cost somewhat a lot but provide up to par service.
1. firebase real time database. This one is really easy to implement. Using firebase almost completely solves your backend needs. You will mainly need to write the frontend. It comes with easy to use library. You can use it with react, angular, vanilla javascript or any one of the other frontend frameworks. This one is really easy to implement. It basically connect your frontend with a real time publisher/subscriber to the firebase. It's also scalable so you will not need to maintain any server or scale up or down your servers. The pricing is also flexible and you only pay for usage. The downside of firebase is that it might not fit to you stack. I don't know what your stack is but you will might need to fit it to your stack.
2. This one is also easy to implement but will require you to write the backend service. ec2 + Node Js + express server + socket.io + typescript + mongodb/sql/database you already use + s3 as file storage. This one is also easy. setting up socket api on ec2 is really easy. It can easily take 20,000 connections per day with the small ec2 that cost something like $5 to $20 per month. I guess you will need to write something like 600 lines of code to set it up but if you need security + validations + types it will might be 1200 lines. if you are already using AWS it might be better. Again from my experience the t2 can easily take the load. We are currently using this stack to download over 10 million of records every hour and to sync it to our marketing dashboards.
Should you buy? Well, I don't know what is the costs of buying. I never did research on buying white label chat. I also don't know how good are the chat solutions that are available on the market and I don't know if you will be able to adjust it to your needs or to provide a better experience to your users. Plus you will also need a developer to build the integration.
Should you build? Definitely build. It’s easy. If you plan to build i guess you will need 1 developer for max 1 month of work (including the frontend and the backend). That is if you already have the ui/ux ready and set in place. So i guess the costs of building is something between $5000 to $15000 (frontend + backend) depending on the developer you hire.
Anyway building a chat app is easy. It's not something tricky. I guess it will take you max 1 month for a finished product. I would definitely choose to build.