Gorbachev is 91 and still alive.
270 karma · joined February 24, 2012
And AvantGo web browser, which primary mode of operation was syncing pages with a desktop computer to view offline.
Granted, it still happened about a decade and a half ago, so I hoped the sarcasm using the word "new" would come through.
mod_wsgi is a much less flexible setup when it comes to mixing and matching different python versions
While the industry was largely distracted by various NPM packages, the foundation we are building sites on got really nice. And I believe in some situations there's value in trying to use this foundation directly, not via a plethora of abstractions. Browsers are great, DOM API is great (well, certainly provides some really nice utils we previously had to look for in external libraries like jquery). CSS is great. I will write "display: flex;" multiple times just because it feels nice to type that, compared to the dance we had to do a couple of decades ago to achieve same layouts.
Static sites are great. They are fast to build, and they build fast. They are really easy to deploy as well. And they also work really well on end user devices. No single line of JS required, but if you want to have some liveliness on the page which can't be easily achieved by CSS animations, very few lines of JS are actually required nowadays. And 0 NPM packages.
Modern JS web frameworks do solve problems some people actually have. But they're best suited for big corporate style webdev. For personal projects I prefer something more… artisanal? Dunno, it's like building a piece of furniture yourself instead of buying one from IKEA. Probably less practical, but feels nice. And may actually fit better in this one weird corner you have.
For ones I saw, the answer to the question "how do I run our project on a single laptop?" is "haha, you don't". That makes features which could take hours to implement take weeks. But deployment is 5 minutes instead of… 15? Not too worthy of a trade-off.
Your CSV writer probably has both technical and organizational reasons being an independent unit of development. Or, in other words, something which appeared organically, rather than someone deciding months prior before a project even started that authentication and user profiles should live in two parallel universes.
Organizational reason would be multiple people/teams who don't want or can't talk much to each other, so they develop pieces of a larger system as relatively independent projects, with clear API and responsibility boundaries. Frontend/backend style web development is an example of such approach, even though we don't typically call these parts "microservices".
A technical reason I can see is some component of a system actually having to be written in a different stack, or to be run in a separate location for business reasons (separate physical computer, separate VMs or containers don't count). Like a firmware running on an IoT system. Or most of the system uses python, but there's a really good library in java for solving some very specific problem, so let's use it.
If neither of these reasons stands, you don't have a microservice architecture, you have a distributed monolith. You just replaced some function calls with RPC. RPC call which takes a much a longer time than a local one, and can randomly fail. Most of your microservices are written in a single stack, so you refactor common parts into a library, but then different services are stuck to use different versions of this library. You end up with a much slower and a much more fragile system which is harder to work on for no good reason.
It's the same kind of a concern as having a user input inside HTML served from a server in the first place. And typical backend frameworks people would use with HTMX are already good at mitigating XSS inside served HTML.
Can this be a 3rd party service? It certainly can be, but it's hard to make a generic one for any kind of webhook. Some marketplaces expect a dynamic response, like replying the order number we assigned internally (I typically just echo back the number they gave us with some prefix, but it's still more smarts than just replying with empty 200 OK).
And I've seen services which aggregate popular local marketplaces into API which is easier to work with, but they require to concede some other parts of the business we'd rather keep in-house, like assortment and inventory management.
We're in the business of selling things, we're not in the business of building HTTP services. Our ERP-like thing is down for maintenance from 10pm to 11pm, so we can't use it as a platform for responding to webhooks.
I'll hack something together in a pinch when it's the only way to get orders from a marketplace service, but then eventually I'll have to explain to my colleagues how to linux, how to HTTPS, how to python, how to WSGI, and all other stuff our company typically doesn't do, but has to do now, because this particular marketplace wants to POST orders to us.
https://openvpn.net/community-resources/connecting-to-an-ope...
https://www.youtube.com/playlist?list=PLowKtXNTBypGqImE405J2...