For a very large database where the count would be filtered based on status of the conversations and running this query for every single support channel would be expensive would it not?

Probably less expensive than Redis.

Given that the SQL approach is the standard one, I'd personally expect load testing to demonstrate that it didn't scale before doing something unusual.

Yup, this is exactly why I went a Set. The fact that it can't contain duplicates is super handy

We use twilio.com for the WhatsApp API

Yes but each order has a unique ID which only the customer who placed that order will have access to. If that customer decides to share that URL on his own discretion that is fine by us

Hello, Author here.

Could you elaborate on what part of the maintenance would be messy? I was under the impression that maintaining this would be quite easy because there is no physical server present anywhere in this setup.

Not OP, but I think you should be fine. It can get messy if you're using it as a backend for an application that may at some point have different versions in the field (or dev/testing/staging) so you need to support multiple versions of your APIs. It's not impossible, but it can get messy. If anybody has some good rules/frameworks to organize that kind of thing, I'd appreciate a reply.

Hello, author here.

My bad for not giving a more appropriate title for the post. You re right this setup does not take the backend APIs into account. In our case we use Lambda for the backend APIs so that is also serverless but I failed to mention it in the post.

Hi, also curious how you integrated WhatsApp messages to user for confirmation? Is it business api and is the pricing an issue? (I’m in India too and think WhatsApp api is a bit expensive especially for a use case where I initiated the messaging like in your case)

If you do a follow up on how your frontend and the Lambdas work together please post it, that would be super interesting to me.

Hello, author here.

Thanks for the information. I guess we never encountered this because our application is in react js framework, so once the build is done it creates just one index.html file and there are no subdirectories.

But this is duly noted

Thanks, that makes sense - I've not used ReactJS, but guessed that your site only needed the top-level index.html, so that was handy.

Not exactly sure what you mean by shared hosting. Could you elaborate? Also would this be hosted behind a CDN?

I think they mean a traditional web host that has a ton of sites crammed into a single server and a cpanel. Like bluehost, dreamhost, etc.

Ah, I see but hosting the site behind a CDN is imperative in our case so this would not work

Happy to help :)

Hello, author here.

Like I mentioned in the post, there is no way to programmatically upload anything to the Shopify CDN and the CDN cache cannot be invalidated once you upload a file. If you want to update an existing resource, all you can do really is upload a new one.

This ofcourse still does not completely prevent people from abusing it, but it does restrict usage to a large extent. There is also the issue of giving out a cdn.shopify.com link to your customers instead of something that has you company branding on it. This is not a problem for us because our customers do not have to manually add this snippet to their website and we do it via an API instead, so this link is not apparent to our customers