I’ve got some JSON being served to an iOS App from the cheapest of hosting which is ~5 lines of PHP to get the data from MySQL and return JSON. It’s been running unattended for a decade….
The good ol’ days
You can serve static data over HTTP
31–40 of 127 posts
Re: You can serve static data over HTTP
#32KISS 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.
Re: You can serve static data over HTTP
#33The python server is not meant for production, serving files from it is incredibly slow and resource intensive. It also is not full webserver. There are better options for serving files
Re: You can serve static data over HTTP
#34> You can serve static data over HTTP
Yes. Just like you can put letters together and form words. It's kind of what it was designed to do.
Re: You can serve static data over HTTP
#35I built and API for an internet radio station archive. Initially I tried to build an app but instead I realised I can run a scheduled Github Action that runs every hour, scrapes the archive, builds a Json file and deploys it to Github Pages for free: https://bd.maido.io/api.json
Re: You can serve static data over HTTP
#36caddy 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?
It’s pretty easy, but I find the config file format rather confusing. In the classic Unix style, you’re learning yet another little language, so there’s a learning curve. Once you learn it, it’s fairly powerful and expressive, but the docs aren’t very clear.
Re: You can serve static data over HTTP
#37The python server is not meant for production, serving files from it is incredibly slow and resource intensive. It also is not full webserver. There are better options for serving files
[flagged]
Re: You can serve static data over HTTP
#38Had a smile reading through this. So many web developers out there who have no idea about history of HTTP. That it was designed for static document serving and since been twisted to serve applications.
Re: You can serve static data over HTTP
#39Not from a modern developer. You need to jump down the rabbit hole of the history of solid and proven solutions. Indeed. I've noticed an increasing number of people who call themselves "developers" and appear to create software, but all they can do is follow step-by-step tutorials to glue together some massively bloated thing that they have absolutely no understanding of, much less the skills to debug it when somethi…
At some point, the plane flew so high above the clouds, and it hasn't seen the ground for so long, the passengers might think the clouds is the ground.
Re: You can serve static data over HTTP
#40KISS 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…
That sounds like a PITA solution more than KISS. That said, I'd rather walk into that business and solve that problem, than walk into a business that is fully cloud serverless hooks all over the place.
So yes, Kiss is good until it isn't... because it wasn't kiss anymore. Moving to the postgres solution sounds like it's the new Kiss.