4 ms·

Cloudflare has a simple example of building real time chat using their infra: https://developers.cloudflare.com/workers/tutorials/deploy-a-realtime-chat-app htt

Cloudflare has a simple example of building real time chat using their infra: https://developers.cloudflare.com/workers/tutorials/deploy-a-realtime-chat-app https://developers.cloudflare.com/workers/tutorials/deploy-a... (and source code for the actual app: https://github.com/cloudflare/workers-chat-demo 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?)

edweis 2y ago
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.
- solardev 2y ago
  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!
  - edweis 2y ago
    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).
toast0 2y ago
> 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.
- solardev 2y ago
  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...
  - toast0 2y ago
    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.

edweis 2y ago

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.

solardev 2y ago
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!
- edweis 2y ago
  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).

toast0 2y ago

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

solardev 2y ago
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...
- toast0 2y ago
  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.