41–50 of 113 posts
What am I missing? A highly performant web server like nginx. Static html content. Done.
A way for government employees who don't know what a command line is to edit it. Fault tolerance in case something happens to your web server. A way for people to read it offline when their internet connection goes down (presuming they haven't saved the HTML).
What am I missing? A highly performant web server like nginx. Static html content. Done.
A way for government employees who don't know what a command line is to edit it. Fault tolerance in case something happens to your web server. A way for people to read it offline when their internet connection goes down (presuming they haven't saved the HTML).
I like the idea of this but the process required to deploy it needs to be more carefully thought out. As it is, this currently assumes that any local agency or whatever contractor it works with will: * Be familiar and comfortable with npm * Be familiar and comfortable with netlify * Be aware of this as a possible option The bar for these folks is pretty darn low. A lot of organizations end up contracting with individ…
Earlier quoted context omitted.
A way for government employees who don't know what a command line is to edit it. Fault tolerance in case something happens to your web server. A way for people to read it offline when their internet connection goes down (presuming they haven't saved the HTML).
I disagree that this approach is any better than your standard static html and nginx. In an emergency situation I would want to reduce the footprint for error and keep everything as simple as possible. A CMS is totally overkill for this. There is nothing wrong with having a developer write HTML based on a word document given to them. If it were a true emergency that developer resource would be dedicated to doing this…
People forget how simple the web can be.
> 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
If it's all client side s3/cloudfront and you're done. Costs pennies. You can go super jank using s3 only with simple sites but realistically you're going to want TLS at some point.
People 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…
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.
What we did for tacticalvote.co.uk: 1. A static site generator, with markdown as the source input in Github 2. Data from Google Sheets 3. A bash job on a cron that would poll both for changes... if changes exist, re-publish the site or data and purge Cloudflare cache using their API 4. Configure Cloudflare via Page Rule to Cache Everything Even with a very high change rate and hundreds of thousands of visitors a day…
The builder just rebuilds when someone pushes to master and then scps to the VM. We've been trying out Forestry.io (linked to github) as a management client so that non technical authors can add content. It works to a point, but there are odd things like forestry has poor support for media that's not an image, and doesn't have a concept of folders. So everything gets thrown into "/media" which I hate. Also because it's using git as the database, it commits every time you save, which of course triggers a build. So if there was a way to add releases in forestry that'd be ideal.