root993

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?

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.

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.

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

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

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

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

Hello, author here.

I totally agree on Lambda first. The only reason we did not do that is because when we started this product I was not well versed with Lambda and serverless and preferred to work with something that I dealt with previously.

If I could go back in time, I would set up all our applications on serverless.

I hate to admit it but the nginx server infact is a SPOF.

We currently handle it by setting up alerts all over the place so I can take quick action if something goes sideways, but other than this I have not really found a way around it.

We also have latest snapshots ready of all our instances so that I can get another server running ASAP during a calamity.