Live data from Hacker News

A Starter Kit for Emergency Websites

mxb.dev

61–70 of 113 posts

Re: A Starter Kit for Emergency Websites

#61

Let's pretend we are not web developers for a second. How do I build this website if I don't know what static page means?

I don't think this is the sort of thing a non-web developer should try to tackle on their own. If you are building something for emergency information, there is a lot of risk (loss of life?) if you can't get your message out. Hire someone who knows how to build a scalable website. This isn't a horribly hard problem, but it's easy to make a mistake.

I don't think a developer should be required. This is the perfect time for the squarespaces and wixes of the world could offer minimal templates that do the job. They already have the infrastructure, and bombarded people with ads for websites.

Re: A Starter Kit for Emergency Websites

#62

Let's pretend we are not web developers for a second. How do I build this website if I don't know what static page means?

This is a great question. Usually web developers aren't in charge of these projects, local city and state officials are. We should assume they're not technologically inclined. How can the information presented help them?

I wonder if there's room for a startup here, automated offsite emergency pages for town and city officials to use to quickly publish information.

Re: A Starter Kit for Emergency Websites

#63
post #7

> progressively enable offline-support w/ Service Worker I'm a bit confused about this point. If it's a basic static site why would this be needed?

So that you can revisit the information even in the event that you loose internet access

Interesting, I always thought it would have served the cached page for some reason

Re: A Starter Kit for Emergency Websites

#64
I 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. For reference I'm based in Melbourne, Australia, and have a 100mbps download, 50mbps upload connections:

  $ ab -n 10000 -c 100 https://emergency-site.dev/
  This is ApacheBench, Version 2.3 
  Copyright 1996 Adam Twiss, Zeus Technology Ltd, http://www.zeustech.net/
  Licensed to The Apache Software Foundation, http://www.apache.org/
  
  Benchmarking emergency-site.dev (be patient)
  Completed 1000 requests
  Completed 2000 requests
  Completed 3000 requests
  Completed 4000 requests
  Completed 5000 requests
  Completed 6000 requests
  Completed 7000 requests
  Completed 8000 requests
  Completed 9000 requests
  Completed 10000 requests
  Finished 10000 requests
  
  
  Server Software:        Netlify
  Server Hostname:        emergency-site.dev
  Server Port:            443
  SSL/TLS Protocol:       TLSv1.2,ECDHE-RSA-AES128-GCM-SHA256,2048,128
  TLS Server Name:        emergency-site.dev
  
  Document Path:          /
  Document Length:        4836 bytes
  
  Concurrency Level:      100
  Time taken for tests:   106.534 seconds
  Complete requests:      10000
  Failed requests:        0
  Total transferred:      53220000 bytes
  HTML transferred:       48360000 bytes
  Requests per second:    93.87 [#/sec] (mean)
  Time per request:       1065.345 [ms] (mean)
  Time per request:       10.653 [ms] (mean, across all concurrent requests)
  Transfer rate:          487.85 [Kbytes/sec] received
  
  Connection Times (ms)
                min  mean[+/-sd] median   max
  Connect:      713  808  30.7    803    1828
  Processing:   230  236   4.8    236     443
  Waiting:      230  236   3.9    236     310
  Total:        956 1044  31.7   1039    2067
  
  Percentage of the requests served within a certain time (ms)
    50%   1039
    66%   1047
    75%   1053
    80%   1057
    90%   1070
    95%   1082
    98%   1107
    99%   1168
   100%   2067 (longest request)
I know there's much better ways of testing load/performance. It's just what I had on hand.

Re: A Starter Kit for Emergency Websites

#65
> 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 updates, it could (depending on other factors) be a simpler solution to implement.

Re: A Starter Kit for Emergency Websites

#66
post #7

> progressively enable offline-support w/ Service Worker I'm a bit confused about this point. If it's a basic static site why would this be needed?

So that you can revisit the information even in the event that you loose internet access

The browser cache was supposed to handle this. Kind of stupid that you have to implement your own cache in JS now cause the browser can't be trusted.

Re: A Starter Kit for Emergency Websites

#67

Or 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.

This.

It would be nice to fork the project and do something similar with CloudFront. Any static object data can also be fetched from CloudFront as JSON files, and periodically updated by cache invalidation or cache expiry dates (ie. cache for 5 mins).

Re: A Starter Kit for Emergency Websites

#69

Or 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.

You lost most municipals with this. Yes, even this is too complicated.

Re: A Starter Kit for Emergency Websites

#70
I 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.
Post reply on HN