The Post-Jamstack Era: Just Use Rails(judoscale.com)
judoscale.com
The Post-Jamstack Era: Just Use Rails
https://judoscale.com/blog/post-jamstack-just-use-rails
7 comments
I’ve always been a bit wary of putting a static site on S3 specifically - what happens if I piss someone off, and they have a botnet just load my site a zillion times? A few kb * a zillion = large egress bill.
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.
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.
This is what the CDN is for.
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.
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.
In your hypothetical scenario this is a potential problem regardless if you make static content or not.
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.
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.
You can host somewhere where it is mainly limited by bandwidth instead of traffic. So something like a hetzner dedicated server wouldn't be impacted by this (it's 1GB/s unlimited). The worst that can happen is that your site is sluggish or that hetzner takes it offline due to excessive usage (but I've only heard that happen when you use the full bandwidth for weeks and it is your fault).
Plenty other providers have similar offers, its not a given that you pay by traffic.
Plenty other providers have similar offers, its not a given that you pay by traffic.
Putting it on a $10 VPS means it costs $10 whatever happens. How to limit spend like this on static storage providers?
ah I misread it, thanks for clarifying what they were trying to say.
> does anyone have a reason to think this isn’t a real concern?
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.
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.
Difference is that I don’t usually care if a static site gets DDoS’d - They’ll get bored eventually, and it’s not that important to have uptime. I do care about DDoS’ing my wallet.
That's what the CDN is for
What even is JAMStack? To me it’s a meme that no one can explain yet fits what ever definition you want it to be.
If you are going to create a static site, do not use Rails, use jekyll or something similar, they are built for this.
For static websites, I use GitHub Pages (or GitHub wiki), and for some of those websites custom domain. I edit websites static HTML/CSS locally, commit and push, or edit at GitHub website.
Installing Rails means installing very many Gem packages. That is just too much.
Installing Rails means installing very many Gem packages. That is just too much.
Over two decades ago, folks did this using web server paths with index.html prioritized over e.g. index.php or index.cfml or whatever.
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.
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.
If the author truly is using nextjs just for static, then it should be a simple compile and host the output folder?
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.
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.
did the author forget the age of mobile phones? You need an API anyway.
This post has successfully convinced me this company is full of retards. Great job.
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.
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.
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.