Hacker News new | past | comments | ask | show | jobs | submit login
Ask HN: How hard is it to build a B2C chat?
17 points by edweis 8 months ago | hide | past | favorite | 20 comments
We are running a B2B SaaS company[0] which turns an e-commerce store into a multi-vendor marketplace.

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




Cloudflare has a simple example of building real time chat using their infra: https://developers.cloudflare.com/workers/tutorials/deploy-a... (and source code for the actual app: https://github.com/cloudflare/workers-chat-demo)

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?)


> Doing this with serverless might be a lot easier than building the global network & edge infra on your own.

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.


My opinion/bias is that small companies shouldn't continuously reinvent the wheel and sacrifice end user UX just to keep things in house. I've been at so many companies that insisted on building some shitty in house version of some commonly available thing, done with minimal QA and scaling and UX design. A couple years later it has to be completely rewritten anyway but the people involved in its initial implementation are all gone and a bunch of new mistakes are made. If it's not a core business function / major feature, why not outsource it, if not at the app level, at least the platform level?

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...


Running ejabberd isn't reinventing the wheel though. And it's a battle tested approach to building a chat service, weather it stays on ejabberd or morphs into something else. IMHO, better than getting locked into a single vendor system.


We are using AWS ecosystem and found it was cumbersome to do a websocket MVP with lambdas and API Gateway. We'll check cloudflare's implementation.

Front end is not an issue, we need reliability and performance. Using Cloudflare D2 is also appealing.


In general I've found Cloudflare dramatically easier to work with than AWS (as an individual dev, maybe not as a billing admin or whatever). Their services and APIs are a lot better thought out and documented, IMO, and their serverless stack in particular seems stronger than AWS's.

Just anecdotal though. I have no data to back this up and this isn't my area of expertise. Good luck!


I am a Cloudflare fan. I wish there wrangler deployement was easier, I tried to get into it three times and every time I encounter an issue (typescript compilation or missing dependency).


I’ve done this before as a swe. We used Go and our chat system had auth, file sharing, 1:1 and group messaging, and other features.

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.


Amazing. That’s the perfect scenario for us.

Did you choose go for its coroutine or because it’s your stack language ?


Great. I used it because I prefer Go for all my backend tasks. Great performance, go routines and std library are awesome.


Curious. Did you use some type of websockets ?


Yes. Sockets to push, http post to create message tho or upload stuff.


I see "chat" as tricky to program because there is something mixed initiative about it. Either I can post a message at any arbitrary time or anybody else in the conversation can so you have to do network I/O with a rather complex choreography.

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.


I see, thank you for your input.

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.


| something I'd do for fun for learning - Yes. The answer that comes above is good from web specs pov (or theory in general), otherwise it's not, as it complicates things.

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.


Buy it. Will take a great backend engineer at least a week in the best of conditions to do this, and another week for the frontend engineering.

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.


Keep in mind that a proper implementation and upkeep for (for example) Intercom is not free and will also take many days. Then comes the follow up work with refinement, extra integrations, etc. Then there's support for all the adblockers that disable a third party solution.


Chat is one of the hardest things to build and maintain. It was about half the effort of my past job. But it was mostly scope creep. We did text, image, audio messages, files, then this would break based on different phone models, different OS.

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.


Well i don't know about your stack but from what you describe I can definitely suggest 2 solutions. Building a backend for a chat is easy. At my company, a medium based startup, I'm responsible for writing full stack solutions for our clients.

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.


Build. Just use Convex.




Consider applying for YC's Spring batch! Applications are open till Feb 11.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: