The Post-Jamstack Era: Just Use Rails
judoscale.com
judoscale.com
If you're hosting a static site... life is easy. Throw your content in any s3 compatible storage and point a CDN at it. Done. It will cost literal pennies a year (The domain name will be by far the most expensive piece, and lots of places will give that to you for free if you don't care about being a subdomain).
That too complicated for you? Host it on a raspberry pi out of your bedroom. For the vast majority of traffic loads... that thing is going to be A-OK, even on a crappy consumer line (You'll probably be violating your TOS with your provider if it's a commercial site... but I've found they really don't seem to care unless you're causing them headaches, and a static site ain't gonna cause many headaches).
That too complicated for you? 10 lines of js with express will stand up a prefectly functional static site. Or you literally just install nginx and configure a single server block.
Static sites are fucking easy. It is ridiculously easy to serve static content these days. And borderline free (again - the domain name is going to DWARF the rest of your costs combined, even if you're only paying 5 bucks for the name).
How do you generate your static content? Who cares - do whatever feels best to you (I personally think rails is a bonkers solution, but if you want to use rake tasks to create your output... more power to ya?)
It really sounds like the author doesn't understand what a static site is, because JAMstack also isn't a static site solution (It has API right there in the name).
If you need to be consuming APIs with changing data... you aren't a static site (even if the html/js/css you serve happens to be static). In which case... rails is a fine choice, but if you're only serving the html/js/css and hitting 3rd party apis... I would still recommend an s3 bucket with a CDN.
I haven’t really sat down and done the numbers; does anyone have a reason to think this isn’t a real concern? I’d love to stop worrying about it.
Any time you are doing anything with AWS, set up billing alerts. You likely will never need them, but it is free insurance.
I suppose it is, but it's possible for someone to DOS a $5/month server too (touch wood they don't).
AWS could get expensive but it will always be up, so there's a trade-off there. You could use AWS WAF to mitigate someone running up your bill, but I'm not sure how well it works/how easy it is to configure/how cost-effective it is.
At least the static content is potentially less resource heavy but I don’t see how your concerns don’t apply to any online service.
Plenty other providers have similar offers, its not a given that you pay by traffic.
Ex - Cloudflare has a flat-rate CDN that has no price changes based on bandwidth spikes, and is free for non-commercial use.
Cloudfront is free up to 1TB of egress.
BunnyCDN is a penny a GB.
etc...
And they basically all include DDOS mitigation - so if it's DDOS instead of actual traffic, you usually aren't billed for it.
Not to mention, you'll usually get much better regional performance, since they'll just cache it and serve it from a local instance closer to your user.
You're still going to pay egress with a VPS. So a CDN makes sense in either case.
Installing Rails means installing very many Gem packages. That is just too much.
When you'd build the page dynamically, you'd also write a static .html before serving the html to the visitor. From then on, the .html got served.
On a new build, you'd rm the .htmls.
Back at the time, it seemed to be "the simplest thing that could possibly work" for multiplying a server's traffic capacity by 10000.
Strange to say use rails for static, but the author argues how server less is a nightmare. Though, I also think the same, use nextjs just for the react frontend and a proper backend.
Just use hugo/whatever and host on s3. This shouldn't even be a debate, let alone they've already done 3 rewrites. Bunch of clowns.