Earlier quoted context omitted.
You'd be surprised talking to the younger crowd.
Some time ago, a website was posted here (forgot the topic) which consisted of .md files, and a JavaScript library which would then, on the client, render the markdown on the fly. Why on earth the markdown was not pushed through a renderer so that then the server could serve static HTML is probably a question that only occurs to old timers like us.
You can serve static data over HTTP
61–70 of 127 posts
Re: You can serve static data over HTTP
#62The 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
Ofcourse, this was just an example. One of the prod solutions can be Nginx.
Re: You can serve static data over HTTP
#63Not 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…
> glue together some massively bloated thing that they have absolutely no understanding of Welcome to the world of npm and supply-chain hell
Here's what I mean. There's a difference between:
* Using an IDE knowing what you want to do but you just like the convenience. You know what the IDE is doing for you, but you want your tool to do it for you quickly and get out of the way. If the IDE does something you don't know, you try to learn what this was.
* Using an IDE because you literally can't work without one. Not knowing your programming language and depending 100% on autocomplete to do most stuff. Not even knowing how to write the files that the IDE automatically updates when doing certain things.
It's a subtle difference, but the former is more likely to leave better comments in a web-based code review ("pull request") than the latter.
And if a project consists only of the latter type, it's unlikely that there will be comments like:
* "Use this other class with the same name but different package because this one is buffered" (because depending on autocomplete without knowing the language prevented them from even caring about which import to use, or the difference between those, as long as it works).
* "Would this change affect this other file that's not in the PR but calls this function a thousand times per request?" (because not knowing their own projects general structure due to depending on their IDE for navigation, so they're more likely to NOT notice a file that's not mentioned in the PR).
So if a project has only people that depend on an IDE (instead of using an IDE for convenience), it's easy to end up with stuff that technically works, but copies 40MB of strings around multiple times, and thrashes your performance due to reading one character at a time without buffering.
Granted, this technically is not related to IDEs, but in my experience (emphasis on "my"), most of the people I've worked with that use an IDE, are of the "can't program without it" type, and not the "I use it because it's convenient" type.
Not all of them. But most. Even if there's a learning curve at play here, I'd say there's usually overlap between "use IDE because convenient" and "actually bothering to put an effort into learning".
I understand this is an inevitable consequence of lowering the barrier of entry and making programming more accessible, and it doesn't matter if we're talking about npm, IDEs, programming languages, or anything.
Re: You can serve static data over HTTP
#64> It's not illegal to use static files and it does work. No, it doesn't. Maybe for your personal homepage with three hits per month, but even on a low traffic server, static files gave me headaches. 1) When two visitors write to the file at the same time, the data of one of the visitors will be gone. This can be solved by using lock files. This is a topic on its own (what happens when two processes both create a lock…
Re: You can serve static data over HTTP
#65KISS 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.
I don't know how this will ever not be a complete maintenance hell. It is even far worse than the monolithic "I push every bit that needs to be pushed for the whole enterprise - Sync Tool".
Re: You can serve static data over HTTP
#66Not 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…
You might not want them in your team maybe, but isn’t it really cool we reached a state where you can actually do this? Democratization of software engineering is a great good!
As in be a terrorist and produce bombs? These are all ticking time bombs.
Re: You can serve static data over HTTP
#67KISS 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
#68KISS 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
#69KISS 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…
People should not cache something that changes very often.
Re: You can serve static data over HTTP
#70Earlier quoted context omitted.
not sure that MITM definition applies here: cloudflare is serving the data, they're not in the middle, they're either alice or bob
They do host some data, but they delegate a lot of connections as well. One of their biggest products is bot mitigation, where they'll inspect incoming connections/traffic and pass them through if they don't seem to be bots. This is essentially MITM-as-a-service.