I like your website. Nice and clean. Even the underlying HTML is clean. Well done.
You can serve static data over HTTP
21–30 of 127 posts
Re: You can serve static data over HTTP
#22 caddy file-server
Also:
caddy respond
caddy respond --listen :2000-2004 "I'm server {{.N}} on port {{.Port}}"
cat maintenance.html | caddy respond \
--listen :80 \
--status 503 \
--header "Content-Type: text/html"
Re: You can serve static data over HTTP
#23I was working on content heavy web app few years ago and realised that lot of database reads are happening to very few "popular" posts then it hit me that we can just host that content as json files using Nginx without API getting involved. That worked like a charm. Decreased usage of database, decrease in latency. etc. In hindsight we could have just used CDN but for the shoestring budgets we had, we achieved lot of scalability with single nginx server.
Re: You can serve static data over HTTP
#24KISS is good... until it isn't. At my work I struggle with the opposite: all problems are being squeezed into "let's put it into static JSON on the CDN" - which ends up with a complex custom JSON based language (schema) to support sharing information between apps, subsetting information (ie. search) etc - ie. implementing an ad-hoc one-file database. Ahh... and don't forget about complex CI/CD pipelines and Git setup…
> don’t forget about complex CI/CD ...
So it’s simple or complex because I got confused ;)
KISS is ALWAYS good. But simplicity doesn’t mean easy or naïve solutions. Naïve solutions get very complex since the initial input is low and they don’t cover edge cases by design making it tangled mess.
Simple solutions are often very difficult to create, require a lot of input to be simple, but they cover a lot of cases behind the curtains and are easy to describe.
Your “use Postgres” strategy is more KISS than doing complex mocking. Sure, initial effort is higher, but using well known, powerful yet ergonomic singular entity is as simple as one can get on some levels. It’s equivalent of “just use Excel for it”.
I agree with you, but I think tagline is misplaced.
Re: You can serve static data over HTTP
#25I was working on content heavy web app few years ago and realised that lot of database reads are happening to very few "popular" posts then it hit me that we can just host that content as json files using Nginx without API getting involved. That worked like a charm. Decreased usage of database, decrease in latency. etc. In hindsight we could have just used CDN but for the shoestring budgets we had, we achieved lot of…
A common approach in between these two is to use something like memcached (or redis) to cache the results of common requests.
That also tends to provide results faster than the database layer, so better latency and less database load.
It's not as fast as serving static content via nginx or a CDN though. :)
Re: You can serve static data over HTTP
#26caddy file-server does this, but more production-ready, honors cache headers, sets Etag, etc. Also: caddy respond can be used to hard-code specific responses if you're testing an HTTP client. It can even spin up on a whole port range and supports templates in the response text right there on the command line: caddy respond --listen :2000-2004 "I'm server {{.N}} on port {{.Port}}" Here's an example maintenance page: c…
Is caddy that easy to setup and run?
Re: You can serve static data over HTTP
#27caddy file-server does this, but more production-ready, honors cache headers, sets Etag, etc. Also: caddy respond can be used to hard-code specific responses if you're testing an HTTP client. It can even spin up on a whole port range and supports templates in the response text right there on the command line: caddy respond --listen :2000-2004 "I'm server {{.N}} on port {{.Port}}" Here's an example maintenance page: c…
It would be polite to note that you wrote caddy. (It's a good tool and appropriate here, but disclaimers for self-promotion are always in style)
Re: You can serve static data over HTTP
#28Rails, by default, will put a “.json” suffix on json routes. This is so supremely useful if you have a Rails api app, speaking to some over complicated front end that might need a quick and dirty mock for something. Just serve your /api/thing.json from somewhere. Only issue is with HTTP verbs other than GET, but usually at that point I need a lot more than this 15second mock. Good for testing little things though.
I was about to say this!
Re: You can serve static data over HTTP
#29caddy file-server does this, but more production-ready, honors cache headers, sets Etag, etc. Also: caddy respond can be used to hard-code specific responses if you're testing an HTTP client. It can even spin up on a whole port range and supports templates in the response text right there on the command line: caddy respond --listen :2000-2004 "I'm server {{.N}} on port {{.Port}}" Here's an example maintenance page: c…
Is caddy that easy to setup and run?
I'd say "easy to setup and run" is arguably caddy's entire point:) Single binary file, yes running is that easy for simple stuff, and honestly it's not exactly complicated for more complex stuff. It got a lot of its popularity because it made HTTPS, including automatic cert provisioning, utterly trivial.
Re: You can serve static data over HTTP
#30KISS is good... until it isn't. At my work I struggle with the opposite: all problems are being squeezed into "let's put it into static JSON on the CDN" - which ends up with a complex custom JSON based language (schema) to support sharing information between apps, subsetting information (ie. search) etc - ie. implementing an ad-hoc one-file database. Ahh... and don't forget about complex CI/CD pipelines and Git setup…
What is KISS? Apologies, I'm unfamiliar with some acronyms.