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?
87 karma · joined June 27, 2020
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.
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.
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
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
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.
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.
While this is true, we wanted to go with AWS for 2 primary reasons
1. We use some of the other services provided by AWS like s3 and Route53.
2. Just the reliability and brand that AWS has is something that we had to take into consideration
We definitely considered using other cloud providers like DO, linode, etc. But it was important for us to go with AWS because we needed some of the other services that AWS providers like s3, Route53, etc.
Some of our static websites are in fact hosted entirely using CloudFront + s3 combination which is something I forgot to mention in this post :)
1. When I started working on this I was not fully aware of the large array of services that AWS provides and therefore our setup may not be the best possible one. So I would be checking out Elastic beanstalk for sure and see if it is feasible to use for my next venture.
2. Just to clarify, we are not running mysql on a lightsail instance, rather we are using a managed database provided by lightsail which automatically takes backups on its own and also has the option to restore a new DB from an existing backup.
3. Thanks for the insight on EB. Will be looking into it for sure.
The thought of any of these instances going down scares me as well. but I would like to believe that I have set up enough alerts everywhere so I can take immediate action :)