What do you postgres self hosters use for performance analysis? Both GCP-SQL and RDS have their performance analysis pieces of the hosted DB and it's incredible. Probably my favorite reason for using them.
So, let me get this straight, the "platform fee" is baked into the runner cost, but, their cheapest runner is the _same price_ as the platform fee? So its the same price to have them run it vs have me run it?
I LOVE gitlab, but their new pricing is absurd. It feels like they are trying to shovelware their AI stuff. Their cheapest plan is more than 7x the cost of github, AND more expensive than github enterprise! And thats on the _cheapest_ non free gitlab plan.
If you self host gitlab entirely, you can't even get branch/force-push protection. If they could bring their pricing to even just 2x github by having a NON-AI plan, I would purchase again in a heartbeat.
I had to go check to see what their pricing was, and I couldn't believe it. The base tier was $4/month, now that tier is gone and the premium tier is 2x what it used to be only 5 years ago.
I think "caged" is not "evil" in a lot of people's minds. This is NOT society saying "we will look the other way", it's society saying, "that's not evil"
Also, organic doesn't mean, "without pesticides" it means a lot MORE than that. For example, I have no problem buying genetically modified produce. If there was an option for "pesticide free, but not organic because of GMO" I would probably buy that.
Anyways, my point really being, you can't extrapolate that people are looking the other way because of price. All your examples are more of examples of society not being morally aligned to what you are considering evil.
Micro is a relative term. And was coined by these massive conglomerates, where micro to them is "normal sized" to us.
They work better if you ignore what "micro" normally means.
But "not too too large services" doesn't quite roll off the tongue.
I prefer POST for everything. The main reason why is because HTTP verbs don't match cleanly to every operation. And it leads to a lot of bike shedding around the exceptions. POST for everything, on the other hand, forces you to put the "method" in the request outside of HTTP semantics, which allows you to "just use" whatever verb makes sense rather than trying to map it to the limited ones available.
I'm assuming the case here is lots of query params. Stuff like `?foo=bar&lorem=ipsum...`.
Most likely, you would benefit from making a cirurgical mini-resource on the server.
Introduce `/report/{id}`, and make it into a POST.
The user POSTs to `/report`, and the answer is 201 (Created) or 202 (Accepted), with a `Location: /report/123` (generated short id). The thing you changed on the server, is that now that long list have a short id. Just that.
Then, the user `GET /report/123` (auto redirect). It all happens within the same socket (keep-alive) and it has almost zero overhead (one refresh without this probably has thousands of times more overhead than the redirect).
By doing that, it seems that you are wasting stuff, but you're not.
Now the user doesn't have to transfer huge amounts of query data when GETing the results again, cache layers will have an easier time, and you can even use that mini-resource as a shortcut to solve things like racing conditions (two users doing the same humongous query at the same time).
Realistically, unless you're some query-by-image type of thing (trying to search images that match an existing one), you'll never actually have to face URL limits. If you are one of those cases, then you probably already have other architectural constraints that would justify introducing the extra intermediate resource.
> Fonts looking terrible seems to only be when using an x app on wayland
I suspect the original commenter had an issue with GNOME specifically, as I've noticed it too, on Wayland native apps. GNOME handled fractional scaling poorly, and fonts didn't align to the grid right and looked fuzzy at anything that's not 1x or 2x scale.
reply