81–90 of 127 posts
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…
> 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…
Earlier quoted context omitted.
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".
Best of both worlds.
that's why I really, really hope ActivityPub or Nostr protocol could be designed as static-website compatible. But nope.
You need something to deal with follows (cryptographically verify that the follow attempts actually originate from the servers they claim to) and submitting posts to your followers (push based, not pull based in practice) but all the metadata and user lookup stuff can be done with JSON files in the right place.
I first came across this when creating a demo for a smartpen that was supposed to have live interactivity features, which I was going to implement by putting a little HTTP server on the pen.
When it came to simulating my solution, I took away features until I came up with the "serving static files over HTTP" trick the post describes.
Then I realised that I could do the whole thing by just putting the demo files in a directory and changing the base URL in the client from https://... to file:///...
Another time we built a backend system for feed processing and delayed putting in a database until we discovered we didn't actually need it.[1]. The standard operating procedure at the time was to create an Oracle DB for everything, including a system that needed a total of 6 data items. Wow.
My boss at Wunderlist used to brag that the database we used for the iOS/macOS clients was just a bunch of JSON files in the filesystem. Worked wonders and was really, really fast.
These and many other experiences led me to come up with Storage Combinators[2]. Once you try them, you'll wonder why things always have to be so complicated.
And yes, I agree with the idea that "gluing complex libraries together that we don't fully understand" is a problem. And also with the notion that it's an achievement that we can and should be proud of, at least partially, because that used to be something we couldn't do at all[3]. Nowadays we can at least do it badly[4].
My take on this is that we don't have the right kinds of glue, particularly procedural/functional abstraction is often no the right glue, and OOP notwithstanding that's really all we got. [5][6]
[1] https://link.springer.com/chapter/10.1007/978-1-4614-9299-3_...
[2] https://2019.splashcon.org/details/splash-2019-Onward-papers...
[3] https://blog.metaobject.com/2021/07/glue-code-is-success-con...
[4] https://blog.metaobject.com/2021/06/glue-dark-matter-of-soft...
[5] https://blog.metaobject.com/2019/02/why-architecture-oriente...
For mocks, it's a good idea. For the rest, even for a prototype, it seems a lot of trouble to insert, update and delete data.
But on a(n only slightly) more serious note, maybe the data is generated outside of the web server. Different projects have different needs, but there are plenty of them that just need to serve some mostly static data.
Earlier quoted context omitted.
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.
This technique of producing an “API” from directories of json generated by batch jobs and creative use of symlinks can be surprisingly effective. I wrote a simple program to transform a list of RSS feeds into a directory tree that I’ve been using for years as my feed reader API to great effect.
> 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.