It doesn’t actually require that second part. Every time I’ve used it in a production system, we had an approved list of query shapes that were accepted. If the client wanted to use a new kind of query, it was performance tested and sometimes needed to be optimized before approval for use.
If you open it up for any possible query, then give that to uncontrolled clients, it’s a recipe for disaster.
GQL is an HTTP endpoint. The question is, how are you schematizing, documenting, validating, code-generating, monitoring, etc. the request and response on your HTTP endpoints? (OpenAPI is another good choice.)
Really? Hmm... where in the HTTP spec does it allow for returning an arbitrary subset of any specific request, rather than the whole thing? And where does it ensure all the results are keyed by id so that you can actually build and update a sensible cache around all of it rather than the mess that totally free-form HTTP responses lead to? Oh weird HTTP doesn't have any of that stuff? Maybe we should make a new spec, something which does allow for these patterns and behaviors? And it might be confusing if we use the exact same name as HTTP, since the usage patterns are different and it enables new abilities. If only we could think of such a name...
An HTTP Range request asks the server to send parts of a resource back to a client. Range requests are useful for various clients, including media players that support random access, data tools that require only part of a large file, and download managers that let users pause and resume a download.
Because it solves all sorts of other problems, like having a well-defined way to specify the schema of queries and results, and lots of tools built around that.
I would be surprised to see many (or any) GQL endpoints in systems with significant complexity and scale that allow completely arbitrary requests.
Yep, OpenAPI is also a good choice nowadays. That’s typically used with the assumption you’ve chosen a supported subset of queries. With GQL you have to add that on top.
Probably for one of the reasons graphql was created in the first place - accomplish a set of fairly complex operations using one rather than a multitude of API calls. The set can be "everything" or it can be "this well-defined subset".
I think they mean something like (or what I think of as) “RPC calls, but with the flexibility to select a granular subset of the result based on one or more schemas”. This is how I’ve used graphql in the past at least.
> I am wondering why you're using graphql if you are kneecapping it and restricting it to set queries.
Because you never want to expose unbounded unlimited dynamic queries in production. You do want a very small subset that you can monitor, debug, and optimize.
It's not. The fragments you can execute are limited if you do it right. A client isn't allowed to just execute anything it wants, because the valid operations are pre-determined. The client sends a reference which executes a specific pre-planned fragment of code.
In development, you let clients roam free, so you have access to the API in a full manner. Deployments then lock-down the API. If you just let a client execute anything it wants in production, you get into performance-trouble very easily once a given client decides to be adventurous.
GraphQL is an execution semantics. It's very close to a lambda calculus, but I don't think that was by design. I think that came about by accident. A client is really sending a small fragment of code to the server, which the server then executes. The closest thing you have is probably SQL queries: the client sends a query to the server, which the server then executes.
It's fundamental to the idea of GraphQL as well. You want to put power into the hands of the client, because that's what allows a top-down approach to UX design. If you always have to manipulate the server-side whenever a client wants to change call structure, you've lost.
No one exposes SQL to clients though. I think where Gql differs from sql is it’s at a higher level. SQL bleeds performance and data layout (e.g. normalizing, limits), GraphQL does not.
It’s not clear if it’s high enough to abstract knowledge from storage. In the end it’s tension between enabling client to wander around productively vs being a bull in a china shop.
Unfortunately the problem isn't just "the internet sucks" it's "the internet sucks, and everyone uses it" - meaning people are not doing stuff offline, and a lot of our lives require us to be online.
I don't think many look at wealth inequality in isolation, it's usually accompanied by how people are starving. E.g. "over 20 people die from malnutrition in the US but we have over 900 billionaire's" - e.g. each billionaire would probably only have to give $300k each (equiv to what the average tax payer gives to the defense budget each year) to prevent most deaths in the US due to lack of food - etc.
I get the feeling that you're winging the specific numbers because they're spectacularly incoherent.
But anyway, the United States is extremely rich and has essentially no big problems that can be solved by a small amount (say, a few billion) of money. The problems are either so big that it would take trillions to solve (supporting aging population etc), or blocked by something other than money (politics, regulations, etc). The big problems that can be solved just by throwing a few billion at them are solved quite easily by either the government or by private entities like the Gates Foundation.
In practice, it seems that politics generally takes precedence over problem solving. If you look into the psychology of it, neither politicians nor voters are really incentivized to solve big problems. This is especially true for big problems that will take more than an election cycle to solve.
It seems to me that it would be easy to support an argument that suggests more big problems could be solved if incentives were better aligned toward problem solving and if competent people, not professional politicians, were chosen to solve them.
One of the things you learn quickly when you look at these kind of problems is that they’re not so easy to solve with money. The budget for SNAP, the US’s primary food benefits program, is about $100 billion; the additional $270 million you propose would be a tiny drop in the bucket.
In the US, the poorest people suffer from an obesity epidemic. Virtually no one is starving in the US anymore, besides mental health problems or other edge cases creating it.
Volunteering at a food bank in any large city will change your perspective.
If you’re not where the rubber meets the road your knowledge of a system will always be incomplete and inaccurate. Literal trade secret of S Class developers, you’re welcome.
The poor are food insecure. This leads to obesity not because they have access to an abundance of food but because their access to food is not stead, leading to over eating to compensate, and the food they can afford is not healthy.
Are you really claiming that it's cheaper to buy an appetite-satisfying amount of unhealthy food (chips/sweets/snacks/fast food) than fresh vegetables and staples like rice or potatoes?
Yes, both cheaper and more accessible and easier to eat without having to spend the time (which the working poor don't have) to then cook the raw foods. They're called food deserts.
Thanks for the link. I agree that preparation time is an important consideration. I do think that the food desert criterion (> 1.6km to the nearest supermarket in urban centres) seems very restrictive -- this would make half of most suburbs "food deserts" in the affluent western country where I live.
I find the more recent concept of "food swamps", also explained on that page, to be a (perhaps unwitting) direct challenge to the theory that absence of nearby healthy food is the root cause:
> A related concept is the phenomenon of a food swamp, a recently coined term by researchers who defined it as an area with a disproportionate number of fast food restaurants (and fast food advertising) in comparison to the number of supermarkets in that area.[13] The single supermarket in a low-income area does not, according to researchers Rose and colleagues, necessitate availability nor does it decrease obesity rates and health risks
If this claim is true -- that is, if areas with 1 nearby supermarket have obesity rates no better than areas with 0 -- then it's essentially impossible to blame health outcomes on the availability of healthy food nearby. If an area has nearby supermarkets, it is much harder to make the case that obesity is purely the result of external factors outside a person's control.
A fancy Nissin Cup of Noodle is $0.80 and 300 caloriesz. I just bought 2 lbs of hamburger meat for $15.
Food insecure people load up on cheap carbs. Most of them don’t know you to cook or lack gear and will buy a $5/16oz boil in bag rice vs. a 10lb bag for $6.
The rest of the world handles that through PATH/PATH equivalent.
Either the package manager is invoked with a different PATH (one that contains the desired Node/Java/whatever version as a higher priority item than any other
version on the system).
Or the package manager itself has some way to figure that out through its config file.
Or there is a package manager launch tool, just like pyenv or whatever, which does that for you.
In practice it's not that a big of a deal, even for Maven, a tool created 21 years ago. As the average software dev you figure that stuff out a few weeks into using the tool, maybe you get burnt a few times early on for misconfiguring it and then you're on autopilot for the rest of your career.
Wait till you hear about Java's CLASSPATH and the idea of having a SINGLE, UNIFIED package dependency repo on your system, with no need for per-project dependency repos (node_modules), symlinks, or all of that stupidity.
CLASSPATH was introduced by Java in 1996, I think, and popularized for Java dependency management in 2004.
> The rest of the world handles that through PATH/PATH equivalent.
Activating a venv is just setting a few environment variables, including PATH, and storing the old values so that you can put them back to deactivate the environment.
This is wrong. A venv is a hierarchy of folders containing a config file, as well as some symlinks to Python (or stub executables on Windows). "How Python does it" is that when it starts up from the symlink, it looks for the config file at a relative path; if that checks out, it uses hard-coded rules to add another relative path to sys.path. PYTHONPATH is never involved.
The venvs created by the standard library `venv`, as well as by uv (and by the third-party `virtualenv` that formed the original basis for `venv`), also happen to include "activation" scripts that manipulate some environment variables. PYTHONPATH is not among these. It manipulates PATH, so that the venv's symlink is on the path. And it may unset PYTHONHOME.
