Readit NewsNot OP, but it's still an important consideration - one can be both glad Google is working on this, but also cautiously optimistic given Google's history. IMO it's right to be wary of private entities taking care of what should effectively be a public service.
That’s … that’s even worse than people who send errors with an HTTP 200 response code.
> Dear ImGui is designed to enable fast iterations and to empower programmers to create content creation tools and visualization / debug tools (as opposed to UI for the average end-user). It favors simplicity and productivity toward this goal and lacks certain features commonly found in more high-level libraries.
Here's a quote from my comment [1] on an earlier discussion about Dear ImGui vs. "bloated" browser APIs:
> This is what I hear when I enable VoiceOver on macOS and open Discord (either the web app or the desktop app):
> 1. “Discord, friends - Discord window, direct messages, selected cell”
> 2. “You are currently on a cell inside of a table. To navigate the cells within a table, press…”
> 3. (when navigating with the keyboard) “1 mention, $SERVER_NAME, cell” “$SERVER_NAME, cell” etc
> And here’s when I do the same with a random Dear ImGui app I have installed:
> 1. “$APP_NAME, $APP_NAME window, $APP_NAME window”
> 2. “You are currently in a window”
> 3. (when navigating with the keyboard) [silence; no additional instructions]
Seems we should lift up Dear ImGui -- contribute, donate, feedback (document, gather requirements, etc), etc -- as opposed to suggest we not use it.
That's what I thought for a long time about google domains. Yet here we are.
Most of my nightmares with microservices comes from where there has been > 1 per team. That came from people who read his "microservices are great!" blog post and just thought that they should build as many as possible. I used to hate him because of that - because it was a logical response to his blog post and people would use it to justify their technical decisions - with argument-from-authority.
In another company I worked at each team maintained ONE microservice and it worked really well.
Because it was a corporate environment with all the usual power politics, control freakery and lack of effective inter-team communication, even though it was more work overall and definitely a technically inferior solution, it did a neat end run around those systemic corporate issues by giving teams relative freedom of development, freedom of deployment and a deliberately simple, loosely coupled, standardized JSON interface to microservices run by other teams whom they didn't talk to much.
So, I get it, but I lost a lot of respect for him over his inability to parameterize his suggestions and the fact that he didn't seem to initially really understand why microservices worked so well for him.
To me, it's the Clean Code of web services.
Terraform and Ansible look like gyroscopes compared to the build process of any modern software stack. We offered our dev teams a whole ass pizza party every time they had 10 green builds (on main) in a row. In three years we've paid it out once.
I write PHP every day (just took a break from that to be here) and the request scoped content is both a nice thing and a pain in the ass some times. It's great that each request is on it's own - really handy for cleanup like you mentioned. There are some thing I want to be shared though, like a DB connection pool, a caching layer (one layer below my Redis layer), and clients for various other services.
Not the end of the world, but an example is AWS Secrets Manager libraries for Python support secrets caching, but they can't offer that in PHP since we won't be able to share the objects. You can use the file system, but that comes with its own hosts of quirks.
That said, PHP really is a fine language. I'm personally not a fan of the use of truthy/falsy values, but they've really dove head first into solid type support. Lot's of good progress has been made with it.
2005 your average box served some php and static assets, connecting to some generic relational database. Reading logs means grepping files over ssh.
2022 your architecture runs in the cloud, has multiple flavors of databases, queues, caches, and so on. You have at least two orders of magnitude more complexity because you aren’t just serving a web page anymore - you handle payments, integrate with other services, queue tasks for later, and so on. Your automation may be an order of magnitude more complex than 2005, but it enables two orders of magnitude more functionality.
Everything you described was 2005.
If no one is doing it or well, I see no reason to just complain and offer no solution. If there are other solutions and Google is going to hurt or destroy "competition", that's what should be discussed.