Live data from Hacker News

You can serve static data over HTTP

ignore.pl

61–70 of 127 posts

Re: You can serve static data over HTTP

#61
post #56

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.

That specific case sounds like a case of "Because I can and I think it's neat" more than anything.

Re: You can serve static data over HTTP

#62
post #33

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

Adding that to the blog post would strengthen the argument. We shouldn't assume the knowledge level of the reader. Examples become production all the time. Using files with unix philosophy is a tried and tested way to be really productive.

Re: You can serve static data over HTTP

#63
post #42

Not 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

To be fair, I would also say the mainstream IDEs have contributed to this situation to a certain extent, since they lower barrier of entry. That's a very good thing, but also sometimes bad.

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
post #60

> 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…

Sounds like your files are not static, therefore your problem is not the same as the problem the article is addressing.

Re: You can serve static data over HTTP

#65
post #40

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

> fully cloud serverless hooks all over the place

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

#66

Not 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!

> but isn’t it really cool we reached a state where you can actually do this

As in be a terrorist and produce bombs? These are all ticking time bombs.

Re: You can serve static data over HTTP

#67

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

[deleted]

Re: You can serve static data over HTTP

#68

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

[flagged]

Re: You can serve static data over HTTP

#69

KISS 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…

The crazy habits proponent in your workplace is simply ahead of his time: there is the "SQLite for edge" vulgata now and he/she may skim some of the wheel reinvention and funny engineering problems with throwing around SQLite files, like in the good old Access days.

People should not cache something that changes very often.

Re: You can serve static data over HTTP

#70

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

But i think they terminate the SSL connection, and then re-establish a new one right? It's not like your backend server didnt know it's been MITM'ed. I suppose they should've named MITM as Surprise-MITM.
Post reply on HN