No, that's not true. If you share code like this then you can do things like put the same validation code in the frontend and the backend: frontend to give a nice user experience, and backend to protect the endpoint.
OpenAPI does support patterns for fields and nullables/non-nullables - that already gets you very far regarding validation. A decently sophisticated generator (which don't exist IMHO) would generate the validation code for your respective language.
> I see the mistakes being made and know what it will cost (because I've been there and done that many times), I do my best to explain that and recommend alternatives, but more often than not it still happens anyway.
I'm mid-40s (I can't believe it) and I made a slightly different move a few years ago into more senior leadership, where I get more say in how things are done. This is precisely for this reason: I felt the larger problems to solve were in how to protect the team both from unnecessary external influences and from (potentially) overly-loud but not sensible people suggesting architectures that would be a lot of time and not a lot of value. I then moved to another company and retained a similar level of seniority.
I have different challenges now in having more influence (one sees the problems elsewhere that would be fixed if one were in charge of that as well, but one can become blind to issues within one's purview) but I quite like it overall.
The alternative probably is freelancing. Find a niche and occupy it, without charging the earth, and you'll probably do well emotionally and in providing for your family.
I’m mid 40s and took the other route. I was self-taught and decide long ago that I never wanted to manage other people. So instead now I run a small solo audio company. Never have to deal with anyone but my own customers. I consider it a craft not a startup.
It isn’t for everyone but whatever LLMs end up being for us all, in this position they seem more likely to be an asset than a liability. If they are good enough to replace me then they can be my army.
ExFAT is becoming a good option on all three. Windows and MacOS have native support, and more and more Linux distros are getting support as well I believe.
> if deployed at scale (and if not at scale, what's the point?).
The "at scale"s might be very different between "what would be enough to affect local weather" and "what would store all the excess electricity generated in non-peak hours".
> Robert Koch Institute (RKI) – entered a contract on 11 June 2025 to use openDesk as the technical basis for the “Agora” platform for public‑health authorities.
Wow - I was just thinking this would be good. Here in the UK Microsoft are slowly taking over healthcare with their terrible Dynamics 365 platform, and some competition would be really nice.
> If client side needs to be updated about the state of the background task, the best is to send the data to a websocket channel known to the client side.
The state of HTML parsing should convince you that if you follow postel's law in one browser then every other browser has to follow it in the same way.
That's a truism in general. If you're liberal in what you accept, then the allowances you make effectively become part of your protocol specification; and if you hope for interoperability, then everyone has to be follow the same protocol specification which now has to include all of those unofficial allowances you (and other implementors) have paved the road to hell with. If that's not the case, then you don't really have compatible services, you just have services that coincidentally happen to work the same way sometimes, and fail other times in possibly spectacular ways.
I have always been a proponent for the exact opposite of Postel's law: If it's important for a service to be accommodating in what it accepts, then those accommodations should be explicit in the written spec. Services MUST NOT be liberal in what they accept; they should start from the position of accepting nothing at all, and then only begrudgingly accept inputs the spec tells them they have to, and never more than that.
HTML eventually found its way there after wandering blindly in the wilderness for a decade and dragging all of us behind it kicking and screaming the entire time; but at least it got there in the end.
> The state of HTML parsing should convince you that if you follow postel's law in one browser then every other browser has to follow it in the same way.
No. Your claim expresses a critical misunderstanding of the principle. It's desirable that a browser should be robust to support broken but still perfectly parceable HTML. Otherwise, it fails to be even useable when dealing with anything but perfectly compliant documents, which mind you means absolutely none whatsoever.
But just because a browser supports broken documents, that doesn't make them less broken. It just means that the severity of the issue is downgraded, and users of said browser have one less reason to migrate.
The reason the internet consists of 99% broken html is that all browsers accept that broken html.
If browsers had conformed to a rigid specification and only accepted valid input from the start, then people wouldn't have produced all that broken html and we wouldn't be in this mess that we are in now.
