Isn't this reinventing RSS / Atom?
A Starter Kit for Emergency Websites
71–80 of 113 posts
Re: A Starter Kit for Emergency Websites
#72I think this is a great idea, and applaud the idea of bringing a high availability, high-load site template available to others. The number of times I have thought in the past few weeks that if they had just used some static pages on S3 behind Cloudfront, or some kind of CDN, that much pain could have been averted. Of course the first thing I did was to benchmark the test site to see how their edge network performs.…
> I know there's much better ways of testing load/performance.
such as
Re: A Starter Kit for Emergency Websites
#73What’s wrong with just plain HTML and Nginx or Apache?
Not fancy enough to write a blog post about.
Re: A Starter Kit for Emergency Websites
#74Or just create a static HTML file and put the damn thing in a S3 bucket behind a cloudfront proxy. That site is virtually guaranteed to never go down even with insane amoumts of traffic (plus it's edge optimized so a user in new delhi won't be sending requests to your server in los angeles) edit: The whole setup takes like less than 2 minutes and can be even automated it with 2 aws cli commands.
care to write a little howto?
Thanks!
Re: A Starter Kit for Emergency Websites
#75I searched for terms like IPFS and FreeNet in this HN discussion and surprisingly didn't find them. I think distributing to geographically localized p2p networks should be part of any system for emergency websites. An emergency need not necessarily be natural and unintentional.
I love distributed websites, but hardly anyone uses these things. I don't even know of any mobile apps for IPFS, Dat, or FreeNet. They should absolutely be more widespread, but crisis mode website operations need to focus on things the majority of users can access.
Re: A Starter Kit for Emergency Websites
#76People are missing a fundamentally important point. You CANNOT trust fremium services to prioritize your traffic at busy times because they will always cut back free users especially if it's interfering with the service they are providing paying customers. This includes Google Sheets, Netlify, Cloudfront, AWS, EVERYBODY. To create truly fault tolerant services you CANNOT assume a fremium service will go out on a limb…
Most people will run out of money (or the willingness to spend it) long before at freemium hosting would have given out.
Also, for anyone building a site they aren't directly responsible for, getting payment details in a crisis is effectively impossible.
Lastly, don't be so sure services like Netlify wouldn't help if you asked. They often do.
Re: A Starter Kit for Emergency Websites
#77Or just create a static HTML file and put the damn thing in a S3 bucket behind a cloudfront proxy. That site is virtually guaranteed to never go down even with insane amoumts of traffic (plus it's edge optimized so a user in new delhi won't be sending requests to your server in los angeles) edit: The whole setup takes like less than 2 minutes and can be even automated it with 2 aws cli commands.
That's pretty close to what Netlify is doing behind the scenes, isn't it? Why would configuring it yourself be better? Netlify has way more experience at that than most people.
Re: A Starter Kit for Emergency Websites
#78People are missing a fundamentally important point. You CANNOT trust fremium services to prioritize your traffic at busy times because they will always cut back free users especially if it's interfering with the service they are providing paying customers. This includes Google Sheets, Netlify, Cloudfront, AWS, EVERYBODY. To create truly fault tolerant services you CANNOT assume a fremium service will go out on a limb…
Seriously. A single web server with no dynamic content will handle a TON of traffic.
It's really the bandwidth that'll cost you :-)
Re: A Starter Kit for Emergency Websites
#79Can someone explain why I would need a static site generator instead of just writing what I want in html in the first place?
For me maintaining common elements across pages is a reason not to use “just html”
It’s error prone to make changes in the header and footer for example across all pages if you have lots of pages
Re: A Starter Kit for Emergency Websites
#80> When it comes to resilience, you just can’t beat static HTML. We don’t actually need HTML for every case. For even more resilience, we could just push text files with markdown-like formatting characters that people might understand to give the content some hierarchy and emphasis. This would be just content and content alone. Obviously, this wouldn’t be appropriate for all use cases, but if you’re just sharing updat…
Modern browsers are really shitty text viewers, especially mobile browsers. They have unreliable scaling, line wrapping, and are generally piss poor at the task. An HTML document with zero CSS will be displayed far better in browsers. A couple CSS statements in a script tag can make that basic document easily readable and even good looking.
With HTML you have the ability to link to other sites, documents, or anchors in those documents. This makes navigation much simpler than shittily displayed plain text. You're also less likely to have your document mangled by the browser like with plain text.
Also remember just about anyone with a smartphone knows how to navigate the web (links, back buttons, etc). If you break those UI paradigms by sending them plain text documents you've made it harder for a good percentage of the population to effectively use that data.