Honkai Impact 3rd does have pay2win ladder. It's pretty hardcore too, even as a whale it can be quite rough to get to the top. There's a LOT of top tier whales in that game and you need some pixel perfect timings to utilize it at the top level.
It's not just that. A large portion of IT people who work in these industries find Windows much easier to administer. They're very resistant to switching out even if it was possible and everything the company needed was available elsewhere.
Even if they did switch, they'd then want to install all the equivalent monitoring crap. If such existed, it would likely be some custom kernel driver and it could bring a unix system to its knees when shit goes wrong too.
The backend for frontend pattern. Something most apps where frontend and backend are in the same organization (fullstack or otherwise) should have. It does wonder to maintainability and performance.
Even though we use GQL here, we still have a B4F, so it's browser -> B4F -> GQL -> Database.
The tooling we use make it trivial so it doesn't add any development overhead (often reduces it. No CORS bullshit for one), and our app goes ZOOOOOOM.
Not really. The usual strategy for persisted query is to only use them in production or adjacent areas. You build your app using regular graphql doing whatever you need, then after you tested things and it all looks good, when you ship, you parse the codebase, store the queries, and ship them.
It doesn't work if you don't have control over the client (eg: exposing to third parties), in which case query complexity limits are easy to implement and do the job, too.
A lot of the points in the articles are issues anywhere, it just depends on how well they are understood in the context and how mature the tooling is. Eg: rate limiting in REST is rarely problematic because we have no end of WAFs and gateways and circuit breaker libraries that understand REST very well.
It's very true that a few years ago the gap was there, and people implementing GQL had to solve all these problems without access to these mature solutions.
But these days, they're mostly solved problems. Authorization by type that propagate through the graph is pretty simple. Rate limiting and complexity limits on queries is often built in the frameworks. Query parsing is solved with persisted query all the major frameworks have as first class citizen. Performance: lots of GQL caching solutions out there, and the "multi threaded by default" model used by most frameworks helps a lot.
Etc etc etc.
I jumped companies a lot, did both. For a while I too thought GQL was redundant, then went back to a more classic world after a successful GQL implementation. I had forgotten how many problems were solved, especially organizational and people communication issues, through GQL. And so we're moving to GQL again.
Someone in the comment mentioned GQL is a tech solution for an organizational problem. I'll say most good software tooling and frameworks ARE tech solutions for org problem, because technology is usually a solution to people problem. GQL is the peek of that, and it does it quite well. Don't use GQL to solve tech problems, there's better tools for those.
Canada has/had that too. Eg: Montreal used to be a pretty small part of the Montreal metro until they merged all the cities on the island. Even then it doesn't include it's north and south chores.
Consider how the FAA handled the Nextgen project and continually gaslight anyone negatively impacted over the last 10 years, I would be against any airport built within 10 miles of where I live too. Not surprising people would be against it. It doesn't have to be so bad, but it is.
The wcag color contrast algorithm isn't great (and there is a proposal for a better one), but sufficient color contrast is necessary for a variety of visual conditions. That it's not good enough for some doesn't mean it's not more accessible than not doing it at all though.
A while back, a lot of Big Tech platforms (most notably GitHub) switched their "should we put black or white text on this user-supplied background color" algorithm to use the WCAG contrast formula. Doing so caused a lot of white-on-red badges to flip to black-on-red.
Many users reported this was harder to read, even those without the form of color blindness which makes black and red hard to distinguish. Whether making this change was really "more accessible" than doing nothing is therefore pretty debatable, but it definitely helped them pass their WCAG audits.
