The more fine-grained nature of boring REST calls makes it more easy to control client impact on the system.

If you want to see the kind of work you actually need to put in to make a graphql API, look at Shopify. They have rate limits based on quantity of data returned. Cursors and pagination. The schema is a huge ugly mess with extra layers that never show up in the pretty examples of GraphQL on the internet.

Note that even if you use graphql for a private api to your web client, folks will reverse engineer it and use it for their own purposes. There are no private apis on the web.

I'm not a fan of graphql for anything that the public could see. It's somewhat akin to exposing a SQL interface; it opens up too many avenues of trouble. Keep public communication channels as dumb as possible.

We also have user roles, which, if you’re an admin, you can run raw queries of whatever you want, but basic users are locked to the persisted query options.

It’s pretty cool, definitely adds complexity to our builds/permissions, but it works. We rolled our own, but I think Apollo GraphQL supports this out of the box now.

Not saying people should use GraphQL for everything though. It’s kind of overkill for a lot of apps.

I worked with a team that was going down a similar path. At some point it felt like they were reinventing REST on top of GraphQL with a strict set of predefined queries and result shapes.

They hadn't gone too deep into GraphQL tooling so we just switched to REST and implemented those predefined queries. Had a separate, developer-only GraphQL endpoint for prototyping things for a while, but the production stuff was easier to just build out as plain old REST.

I’m not going to argue whether one is better than the other implementation wise. That’s purely personal preference.

GraphQL has one super power though. I have access to an API directly and can save bandwidth by only querying and returning what I explicitly want in the data. That plus the allowed query rules stuff comes free in Apollo GraphQL now. At scale, this is huge for our bandwidth cost savings.

A second big win is federation of many GraphQL schemas under one giant god schema. This is useful when you are a big company, merging two architectures with different API’s together under one umbrella. You can define the mappings from the child schemas to the god schema in another spec that has no code, just a federation schema. Again, you can do this in REST too with layered API’s, but GraphQL arguably makes it somewhat easier to do this with just config files.

I also find that out of the box, the type safety guarantees of GraphQL are a lot cleaner/batteries include than the REST work I did the many years prior.

It’s all do-able with either tech and you are correct in feeling like it’s re-inventing the wheel. It is, and that’s purely a business decision to make money pivoting devs to a new library/environment.

I won’t judge you for wanting to stick with REST. It’s tried and true methods that will work for many many use cases. To each their own!

I don't see how REST is not able to do this, not to mention that REST is very well suited for HTTP caching.

This is not really GraphQL's selling point.

GraphQL's only selling point is this handwaving-driven promise that dev teams no longer need backend work to get an API that returns the data they want.

The promise is that frontend teams simply put together a query and the server magically returns what they want.

Of course the people promising this magic just so happen to be the same people trying to sell you backend services.

One thing you do need to watch for is preventing clients from doing stupid things by allow listing queries or implementing some sort of query cost analysis.

I was later involved in productising said research into an API gateway (called DataPower) offered by IBM. We implemented our GraphQL static analysis in a quite flexible and performant way (all of GraphQL's query validation and the static analysis are implemented in C++). The required configuration for the static analysis can be provided using GraphQL schema directives (cf. https://ibm.github.io/graphql-specs/cost-spec.html). Unfortunately, DataPower is quite inaccessible to the common developer.

I find that persisted queries are a very interesting approach to also solve this issue. They still grant developers the full flexibility to define queries during development, but then require providers to validate and vet queries only once before persisting them (instead of validating and vetting queries on every request). This has huge benefits for runtime performance, of course.

[0]

A very simple convention for including nested resources in a JSON API: https://www.jsonapi.net/usage/reading/including-relationship...

A totally cool but kinda over the top library that exposes a REST API over your database with a very GraphQLesque query string syntax that supports recursively nested resource inclusion, filtering, etc.: https://postgrest.org/en/stable/api.html#nested-embedding

GraphQL falls into the same trap that a lot of things do IMO - it assumes that because 5% of things are complex, that you need a solution that can deal with that complexity for 100% of your API, which needlessly complicates everything else.

Or you could just make an endpoint that gives you the data you want.

It’s pretty neat but nice graphql standardized it so things like consoles and other tools can be written against it.

It gives you all the benefits of GraphQL during development while in production you’re only dealing with JSON-RPC

How is this a GraphQL specific problem?

Obviously you can do either in either. But i definitely think the marketing is world's apart.

So when people come to a problem, if they are not super strong in their understanding of what will be a good solution, they generally implement what the platform markets.

Can you give an example?

query dos { allDogs(onlyFree: false, limit: 1000000) { id veterinary { id dogs { id veterinary { id dogs { id veterinary { id dogs { .....

SELECT * FROM master_table LEFT JOIN sub_table LEFT JOIN sub_sub_table LEFT_JOIN sub_sub_sub_table...

...which is effectively "dump everything". In a REST environment you'll at least need a lot more individual requests - that's both the blessing and curse.

It's that the team maintaining the API is different from the team that needs changes to the API. Due to the scale of the organization the latter doesn't have the access or know-how to easily add fields to that API themselves, so they have to wait for the maintainers to add the work to their roadmap and get back to it in a few quarters. Relevant Krazam: https://www.youtube.com/watch?v=y8OnoxKotPQ

At a small start-up, if the GET /foo/:fooId/bar/ endpoint is missing a field baz you need, you can usually just add it yourself and move on.

Some reasons:

- Front end devs save time by.... sharing queries. So component B ends up fetching records it has no use for because its sharing GQL with component A.

- Backenders never optimise column selection. You may think you are really optimising by sending a GQL query for one column, but the backend will go ahead and collect ALL the columns and then "filter" down the data that was asked for.

- Backenders can also forget to handle denormalisation. If you query related many to many records but the GQL only asks for related ids of implementations will go ahead and do a full join instead of just returning results from the bridge table.

- Frontenders aren't even aware you can send multiple graphql GraphL requests simultaneously.

GraphQL is great, but any technology is limited by how well people can extract its value. I personally feel sometime we'd be better off with REST, or at least make sure people receive the training to use GraphQL effectively.

An unfortunate problem that really only exists with Apollo. Facebook’s graphql client, relay, does not have this issue as it requires each component to explicitly declare its data dependencies.

Citation needed. If two components call into the same data fetching utility for expediency's sake, and that utility queries data that one or both components do not need, you have this problem. What makes that uniquely likely with Apollo?

Whether it’s a React component, or a just a plain old function, Relay has mechanisms to prevent the kind of problem you’re describing. It has a steep learning curve, but it’s very well considered.

In the scenario described, wouldn't this lead to the same problem because someone copied the code or reused a utility from another project and so they have at least the superset of those dependencies plus whatever new ones they added?

Making scalable, well performing queries work is nontrivial, particularly with the current ecosystem of GraphQL libraries. The main workaround for this provided appears to be directly mapping GraphQL to an ORM.

But more and more, I think Backend For Frontends solve this issue in a much better way. And of course that idea isn’t new and Yahoo for instance had that kind of architecture.

Frontend teams get to adjust by themselves a simple interface to their needs, and backend teams can provide more info through internal APIs with less restrictions than if it was directly exposed to the outside.

Going with basic REST gives you simpler caching/optimisation paths, more straightforward mapping between the front request and the backend calls, and it makes it easier for other teams to look at what you’re doing and comment on/fix stuff as needed. GraphQL would be pure syntax sugar, and I’m not sure it would be worth the trade-off.

I disagree, at least compared to something like Apollo Server or Hasura. The mapping is much easier, especially if you consider things like resolvers having parts of the schema going to different backend servers, API endpoints, separate caching, etc.

We tried to do this manually via a REST server, and found that we were just reinventing something like Apollo, but badly.

With that structure you can have any number of layers with your front call and the different business abstractions all representated by an API (let’s say you want a user’s average engagement with a service, you’d hit the high level API, which will fetch access stats from another API, which rely on a lower level API which goes through another separate layer managing DB cache etc.

Most of these call are of course internal to a data center.

So what you can do is some sort of generative graphql thingie when doing your initial iteration, with the client hitting whatever is convenient (in that situation you'd just expose the entire backend unprotected).

Once the needs have gelled out you strip it out and replace the graphql queries by bespoke API endpoints.

I'm a fan of YAGNI, but basic security and leaving your system trivially vulnerable to attacks are a couple of exceptions in my mind.

The other part about team dependence is very true but it also shows a lack of knowledge/thinking/care by whoever formed the teams. It seemed for a while Amazon had things right both in terms of boundaries of teams and in terms of forcing people to use APIs- not sure what they do these days.

Also tends to use a lot less bandwidth.

Compare it to a database, what if you couldn't use random queries with SQL, but only had the option to call stored procedures?

The problem is when genericity diffuses its way into a large system it becomes impossible to maintain. How do you refactor a code base when everything everywhere is just SQL queries. If you want to change the schema how do you know you're not breaking anything? The short answer is you don't and so the software becomes incredibly brittle. The common workaround is testing but you can never test everything and now your tests also become coupled to everything else making things even more difficult to change.

The database in your example, while being generic is already an abstraction of sorts. Now if you're building lessay gmail the external users should see "create email", "get all emails", vs. issuing SQL queries to the database. That makes it easier to change the two pieces (client and server in this simplified example).

I don't even want to think about undoing this mess.

We don't use GraphQL, but we do use an API that is mostly generated from meta data about the schema and permissions on a per field basis, with the ability to override on a per table basis.

To the API consumer it's invisible if they're referring to something that refers directly to a real database columns or to a method on a model class that doesn't correspond directly to the database (e.g. the user "password" attribute is

Effectively there are two schemas: the API schema and the database schema, it's just that the API schema is "prepopulated" from introspecting the database schema using Sequel (Ruby ORM), with the model classes translating between the two, with a synthesised default mapping.

The "API schema" includes more granular type information suitable for the frontend, and permissions, including type information returned to the frontend to provide default client side form rendering and validations (also enforced on the server, of course). It also auto-generates documentation pages with example data, inspired by Airtable's doc pages.

But key to avoiding what you describe is that these are all easily overridable defaults, and the permissions default to allowing no columns, so while the db schema introspection makes it quick to expose things where a direct mapping makes sense, it also makes it easy to avoid.

Unlike GraphQL we explicitly avoided allowing you to request arbitrary complex sets of data, but what you can do is expose queries by defining model metadata for them that either wraps suitable views or custom queries. We have a UI to allow us to define and store custom queries and views for e.g. reporting needs, so we can prototype new API needs in the browser writing just queries with some metadata annotation.

It gets us the flexibility of being able to quickly return exactly the desired data, while retaining control over the queries and complexity.

Of course there are ways to prevent data from being returned but that’s fragile.

For example, field-level security pretty much means every field could be null at any time. Depending on your graphql server implementation, this might cause an entire request to fail rather than just that field to be omitted, unless you change your schema to where everything is nullable.

Checking every field can also easily lead to performance issues, because it’s not uncommon for a large, complex graphql request to have hundreds or thousands of fields (particularly when displaying lists of data to a user).

A proper solution to security/privacy issues should have sensitive data never reach the outermost GraphQL layer.

So the problem is with the existing tooling that enables GraphQL implementations, but like anything else, if that tooling is deficient, the entire approach is on the shaky ground too.

At my current job, this was done before I was involved. It isn’t a deal breaker, but it throws away one of the best features of GraphQL.

In the end you just have every client implement the rules that should have been in an API tier (if they are competent), or worse no validation that gets you a giant mess.

For some reason I don’t think graphql actually works this way. Can’t quite put my finger on why allowing access to any column on a table might be a really bad idea.

I don't think GraphQL makes the problem worse except by encouraging experimentation by putting an unusually powerful query language in the hands of the users

If clever architects manage to expose the carefully segregated database of the small and secure authentication module, they cannot claim it was an accident or someone else's fault,

Privacy

Backend developers describe the data model, expose it via graphql. Front end developers, often ones who never met those backend developers, can see the data model and just use it. They can change what they're querying on the fly, get more or less as they see fit.

It lets everyone move faster.

But as a backend developer, I actually fucking hate it, myself.

You should probably be comfortable enough to work with both ends of the spectrum, but specialization allows you to do a much deeper dive into complex subjects.

A backend engineer probably has a much deeper understanding of every little nuance of their prefered database. A great backend engineer can make sure that you're getting near-optimal performance from every important query.

A frontend engineer probably knows about various UX techniques along with how to avoid unecessary reflows and repaints. A great frontend engineer can implement a UI toolkit as well as advanced techniques such as windowing.

The separation of front/backend has always been mildly entertaining to me and I’ve worked on both teams. Btw, if you ever want to cause a political mess, just submit a PR to add a new API endpoint to the backend team that “doesn’t have the time” to work on it. Woah boy, they will get mighty pissed. As a backend engineer these days, it would be a blessing to get free work from another team… I don’t know why they were so pissed that one time.

The main idea is that writing some code to achieve any particular effect in the system is typically easy. But writing code, that is efficient and maintainable isn't easy. So, there's a team X, which has people working on some specific system. They own the code. To them, their work isn't quite about "implementing requested features". It is about inventing proper abstractions that both reflect the logic of the requested feature and reasonably anticipate the logic of any future feature requests. They want to avoid having 2 implementations of the same thing, they want every piece of code to be idiomatic to their system, etc. And they are right thinking like that, BTW. Every new developer they get is treated with some suspicion at first, and when he learns the idioms of the system he becomes a honored member of the team X. If he fails to learn them, he gets fired or passed to another team, where he may turn out a better fit.

So, for the members of team X, they are professionals, who know how to work on the product and on the system X. Members of other back-end teams are probably not, even if they are good devs otherwise. Some frontend dev — doubly so. Some junior frontend dev coming from military or helpdesk or whatever — triply so.

So, you may think that you are a great and charitable developer, who just implemented a Feature. But to them, you are a lowly ape who made a wobbly hut out of some sticks and leaves that is going to fall down now any moment, and it's going to fall down on THEIR heads (and you will be long gone).

Worse than that, they understand, that other non-engineers (like their manager) also are prone to mistaking a wobbly hut for a Feature. And you basically humiliated them in front of these people by "solving" their problems (while in fact you created more problems). So it gets political here. In fact, because of that, even if the above is not a fair description of your work, they kind want it to be fair, they want you to fuck up, because it at least makes it easier to explain why your help wasn't a real help.

And, in all fairness, it is kinda unlikely that a guy who is new to a codebase didn't fuck up in any way, even ever so slightly. Especially if that's a kind of guy who doesn't understand why dedicated back-end and front-end teams exist.

Oooh, that's an interesting observation. This was so long ago, before I really knew about this attitude. Since then, I've been on these teams and despise that attitude. I didn't even know that attitude existed back then, so this is indeed a possibility.

> And, in all fairness, it is kinda unlikely that a guy who is new to a codebase didn't fuck up in any way, even ever so slightly. Especially if that's a kind of guy who doesn't understand why dedicated back-end and front-end teams exist.

Hah, they couldn't find any fault with the code, the unit tests were even better quality than their own. I also submitted several other PRs fixing bugs that I discovered while writing unit tests. Their reason for not merging the code, after reviewing it, was that the implementation "didn't seem scalable" despite including performance tests showing that it was both faster and used less resources than some of the more popular API endpoints.

When I joined, they kept having GC problems and I pointed out that they were using the Desktop GC method instead of the Server mode GC (this was C# 3.x?) and they didn't even know that that was a thing. They didn't like how some frontend engineer seemed to know more about C# than them.... I imagine that it was a combination of a lot of things, me knowing more about their language than them and not being on their team, plus submitting PRs "showing them up."

This was my first time working at a company with more than 10 devs, so I was used to just getting shit done and not worrying about politics. These days, I know better.

It's an easy conclusion to get to, whether justified or not.

No one likes being made to look incompetent, regardless of whether they actually are.

I have the impression you didn't ask for permission before you did it - the dynamic is wildly different if you start things off by asking if they'd be okay with you taking some time to build it, then involve them in your process as much or as little as they want.

If that's what you actually did, then my analysis is way off.

It is strange to see developers preferring to stay in their isolated environments and not wanting to touch the entire stack.

What a weird thing to say. That was the original state. At some point people started splitting things up because they felt that would be better (or they just weren’t capable of grasping more than one thing?), but I’m extremely sceptical of all this specialization.

If your API looks like this...

  /ios-app/v1/landing-page
  /android-app/v1/landing-page
  /android-app/v2/landing-page
  /windows-mobile/v1/landing-page (legacy)
  /web/v5/...

You might not encounter this problem at any point that's fine - there are other ways to avoid it, like having a cross-platform codebase. I have "hand-rolled" similar solutions to the GraphQL field selection before, and I would use the GraphQL protocol if I were to do it again today.

People specialize in different things. A great React developer may not be a great Java developer, and vice-versa

You may need one or two really great React and/or Java developers.

Nowadays a full stack dev is an intermediate Fe dev, with junior backend skills. He will make your backend un-maintainable. Get a proper master on a proper contract rate to design your architecture.

FFBs and GraphQL is a way to tightly couple to a backend system and then have that backend system loosely coupled.

I guess its all 6 of one, half-dozen of the other, but I usually prefer to just handle things client side. You can maybe get less data transfer optimization but that's down the road from the fast development stage, anyway.

Has this been addressed? I don't see how you can decouple the back-end data from front-end queries without that.

``` const SAMPLE_JOIN_QUERY = gql` query ($main_data_id: String!) { mainData( main_data_id: $main_data_id) { id main_data_field_1 main_data_field_2 main_data_field_3 related_data{ related_data_field_1 related_data_field_2 related_data_field_3 } } } `; ```

    const SAMPLE_JOIN_QUERY = gql`
    query ($main_data_id: String!) {
      mainData( main_data_id: $main_data_id) { 
        id main_data_field_1 main_data_field_2 main_data_field_3 
        related_data {
          related_data_field_1 related_data_field_2 related_data_field_3
        }
      } 
    }`;

(which is often, honestly, an entirely rational decision in terms of prioritising limited resources, but still makes me sad)

On the frontend, you have a choice to use some of the heavier libraries that support all of the features (like subscriptions) - but otherwise, you can just POST a gql query to the server and it will return a blob of json, which really isn't so much more than REST.

The limitations of the query language make code size explode the moment you step outside simple toy examples. It doesn't have any concept of a JOIN, or of the actual relationships between your types (graphql has no concept that me == me.parent.child). You end up writing data loaders for every type so that loops in your schema can be resolved efficiently.

Managing permissions is so much more of a pain compared to REST because exactly what data is returned is so much more dynamic. If you have some confidential data nested 10 layers deep in the query, you get two choices. Either fail the entire query with a NotAllowed based on one deeply nested field that the client maybe does not even care about, or you have to make your schema super loose and make every single field that's subject to permission management nullable. So much easier on a REST endpoint because the response is more constrained.

Our code size for our graphql endpoint has remained totally unchanged for the past couple of years. It took only a few files (of admittedly complex code) to automatically set it up so that it would automatically provide all models via the graphql schema (and a separate permissions implementation restricts access at each level of the schema). It updates automatically whenever we add new models or permissions. This is built on top of Rails and the graphql gem.

My concern is not specialization which I think is necessary for a larger company. It is more the technical solution of "here is GraphQL now your teams don't need to talk and you don't need anyone thinking end to end". I can't believe that is helpful.

I may have created a strawman though?

Segmentation makes some sense but the industry is lacking end to end thinking as you point out.

Until I understood the point, the organizational decoupling. Then it clicked why it's great.

GraphQL is a way to describe not only your API but also the entities and relationships in it. This enables certain useful things for client heavy applications, like cache normalization. If you look at clients like URQL they enable high quality features in your app that are otherwise extremely difficult.

You can also do this with JSONAPI but the GraphQL ecosystem is more developed.

Setting up GraphQL to minimize its rough edges is incredibly difficult. I've currently landed on a combination of Pothos + Genql + URQL to enable me to do everything in typescript instead of untyped strings.

It takes very high skill to use GraphQL well. Few teams get there because they don't have the upfront time to do all the research.

But if you pull it off it can be an incredibly productive system that is friendly to iteration and refactoring. I can send you some content we've produced on this if you're interested.

That said, if I'm not working on a client heavy app, I'd just use a less featureful RPC framework.

This isn’t that though; the first sentence starts “GraphQL is great, but” and then the post lists first “the good” and then “the bad.” Even the provocative headline hedges with “kinda.”

I wish there was more of this sort of balanced discussion on HN. There is a tendency among devs at least in public toward trying to get others to use the tech they use and are excited about, which is understandable, but everything involves trade offs and it would be nice to hear more of those up front (as opposed to one day “mongo is the bomb” and the next “actually mongo is terrible to back to postgres for everything).

while the discussion can be balanced the real world outcome is normally binary: use it or drop it.

i will not start investing huge amounts of time to learn graphql if it has very specific use cases for specific environments. so i naturally look for red flags and objectively negative experiences to see if those might be the roadblocks i would run into 2 months down the line.

imagine a PM coming in all happy "i know nothing about graphql besides the hype but i think it's a great fit for our next project". where will balanced discussion take you there?

It is perfectly fine to start with an early implementation that treats GraphQL as mostly an RPC, with only resolvers for Query & Mutation types. You still benefit from GraphQL's type-safety, batching and code-generation.

Once you have more familiarity with dataloaders, query complexity etc. update your output objects to have links to other output objects building the graph model.

The issue is that too many people get fascinated with GraphQL early, then build deep & complex topologies and expose it in inefficient and potentially insecure way.

First time thinking about the situation, sounds to me like you'd need to just make a new set of roles no? I can't imagine they'd have version support for that, not like the underlying datastore does

On the flip side, you should also be careful of anyone who says some technology is 100% good always. It's far more common to see people talking up the advantages of some trendy new technology without ever mentioning the downsides. All technologies have tradeoffs.

THIS 100%.

> It takes very high skill to use GraphQL well. But if you pull it off it can be an incredibly productive system that is friendly to integration and refactoring.

I could not agree more. It's like any other piece of tech: once you internalize the mental model and are able to translate those abstractions in your language of choice everything clicks. And then it's hard to imagine going back to something more "primitive" (i.e. what's conventionally called "REST").

After building "RESTful" APIs for years I can confidently say GraphQL (with a decent implementation) is a step up across almost every possible dimension (performance aside because of the additional parsing).

While this is true, I think the ultimate assesment of a technology is how easy is it for someone skilled at doing similar work to internalize the model and abstractions.

A tech stack can become really successful only if this is easy and relatively quick, otherwise, it will meet a lot of resistance. Partly because it's hard to master, but partly because so many people will be misusing it (which makes an even bigger annoyance for someone who's trying to get to a proper mental model).

As such, I've come to appreciate only models that majority of developers can easily get right on the first go: or rather, models which are hard to get wrong.

Completely agreed. Without knowing the team experience, greenfield project or not or in general more information about the task at hand, how can anyone say GraphQL is good or not?

One thing I've noticed among some people who've failed to move up in their career is that they carry these extreme opinions due to a proper understanding or a bad experience. Right tool for the job and all that.

Have you never used MongoDB?

A crashing MongoDB instance in default configuration was more likely to lose data irrevocably than a MySQL 3.23 MyISAM setup.

(note that while I still don't particularly enjoy using it, post-WiredTiger MongoDB is a different story so take this as a criticism of the people making choices in the early days, not at all of the current state of affairs)

So what does this mean?

You're saying that in the universe we live in there is absolutely nothing that is 100% bad always. Everything is good for something? There is no concept of bad or obsolete things because it's all good for something?

Let's restrict this to programming languages and frameworks and apis.

Are you saying that in the universe of ALL programming languages, ALL frameworks and all APIs, None of them are at all bad and they are all good for something?

I don't agree with this sentiment at all. In fact I think it's a sign of two possibilities:

1. that the person saying it is highly biased and unable to detect things that are genuinely bad.

2. The person saying it is just being temporarily illogical, there are clearly things in the programming world that are bad. He knows this but is so biased that he's incapable of processing this concept while promoting his favorite language/api/framework.

Scenario 2 is the most likely scenario here. Not saying graphQL is bad. But to love graphQL so much as to say Nothing in the universe is actually bad?

Let's be real, I am not against graphQL. However you cannot actually say that people against graphQL have invalid opinions because there is nothing in the programming universe that is definitively bad. This argument does not make any sense at all.

For example:

1) “Haskell is bad because it’s too theoretical” 2) “Haskell is bad in corporate environments, as its roots in mathematical and academia make it harder for people to get productive with it compared to something like Java or C#”

The difference is clear. In my opinion it’s best if people who care about what they’re saying avoids #1, and instead frames their criticism like in #2.

Note: those examples don’t reflect my actual opinion on Haskell, it’s just something I came up with while writing this.

>The point is that “bad” isn’t a useful descriptor of anything regarding their real-life applications, because it simply doesn’t mean anything.

This is just a complicated way of saying "Bad things have no meaning and don't exist in the universe."

Without getting too pedantic, in general, nobody agrees with this concept. Sure if you get pedantic you may find a couple people in this world who enjoy punching themselves in the face, but in general the overwhelming majority agree that punching yourself in the face is a pretty bad thing.

Note: Punching yourself in the face is just an example of a universally "bad" thing. I'm not personally against punching yourself in the face, it's just something I came up with while writing this.

In my experience when someone says “X is bad”, the response is often either “haha” (which the subject then changes), or “why” (which leads to person #1 actually saying what they want to say). I’m personally not interested in someone’s remarks about some technology completely devoid of context or nuance, and would rather hear about their opinion on such technology in tangible scenarios.

This logic also works for "X is good." or "GraphQL is good". This doesn't really say anything either and is an equally garbage statement following your logic. But your biases focus on the "bad" because you have a bias towards GraphQL.

Either way I don't agree. Saying something like criminals are bad is not an invalid statement.

If you want an explanation you can ask for it. If you don't care to know about the explanation then you don't need to ask for it. But just because somebody makes a statement without an explanation doesn't automatically make it invalid.

For example "The plane is about to crash, please pull up." This is a statement without an explanation (emphasis on the period). Should I demand an explanation or comply without one? In your words, was this statement "really saying anything?" Yes it was.

When you come to threads on HN it's mostly people looking for confirmation of their biases. They don't realize it, but almost everyone is doing this. If you weren't biased you would ask for deeper explanations. You would try to unravel the other persons reasoning and understand it in such a way so that you find a mistake in his understanding or your own. That's mainly why I'm here, but this thread is littered with posts following the same logical path as you.

1) Nowhere in my comments did I say that's limited to negative comments. I think "GraphQL is good" is just as useful (meaning not at all).

2) "Criminals are bad" is not an invalid statement, and neither is "GraphQL is bad" or "GraphQL" is good. But if the purpose is to discuss criminality, and not just add noise to an ongoing discussion, it is also a useless statement. Imagine there's a debate panel going on, someone in the crowd stands up and says "criminals are bad!". Where does that lead the conversation?

3) "The plane is about to crash, please pull up" is an expression of fact, not an opinion, and not even something that warrants or is said in a discussion so I don't think the comparison makes sense. Either way, "GraphQL is bad" is an opinion, not a fact, and thus needs more context to be useful in a discussion.

I'm not going to acknowledge the last paragraph because I'm presuming good faith from you, and I'd rather not turn this discussion into speculation about other comments in this thread or why you're here.

That said, you're definitely right that I'm biased towards GraphQL, but I think we're having different discussions if you think we're discussing GraphQL's merits.

It's not about leading the conversation some place. He's under no obligation to lead the conversation to a place you want it to go. If someone says something different, I don't dismiss the statement. I follow up with a question. You didn't. YOu simply made a broad statement dismissing all queries saying "X is bad" as invalid and you think it's up to the person stating something to explain. No. If you want an explanation you ask for it. But the statement by itself isn't invalid.

However you completely dismissing the negative claim was invalid in my opinion.

>But if the purpose is to discuss criminality,

Obviously this is an example not a segway into criminal law. I am showing an example of a statement that is true independent of explanation. True statements are not to be ignored even when they lack explanations. That is the point.

>"The plane is about to crash, please pull up" is an expression of fact, not an opinion, and not even something that warrants or is said in a discussion so I don't think the comparison makes sense

You can't automatically say something is a fact. It's very possible things like this are an expression of opinion. The copilot observes sensor readings, he thinks we're about to crash. The pilot observes sensor readings he see's no such indication of an impending crash. This is a realistic possibility. The ounter to this is also true. You may assume GraphQL being bad is an opinion, but it's possible that it is a fact.

Let me elaborate on that. What if the person who hates GraphQL is actually expressing a universal fact? But like the pilot you have a differing opinion because you "misread" the sensor readings. Instead of taking the cautionary approach of pulling up and subsequently listening to the copilots reasoning you dismiss a statement because it has no explanation.

The point of this example is to show you a very obvious scenario where it's highly unwise to dismiss a possibly True statement simply because it lacked an explanation. That is my point. You are dismissing a statement that has the possibility of being factually true. And you are saying you don't care whether or not it's true or not if the statement has not auto generated explanation you will dismiss it instead of inquiring further.

>I'm not going to acknowledge the last paragraph because I'm presuming good faith from you, and I'd rather not turn this discussion into speculation about other comments in this thread or why you're here.

fine. The point of me bringing it up is to not make this seem like a personal attack. But to frame my reply as a universal problem among all proponents of GraphQL that are responding in this thread. Basically i'm just reading people Gushing about how great GraphQL is and not exactly addressing why it's also despised by many on HN.

>That said, you're definitely right that I'm biased towards GraphQL, but I think we're having different discussions if you think we're discussing GraphQL's merits.

We aren't, not explicitly. I'm a neutral party with no opinion either way, I'm here to find a side to join. However reading your post and seeing that you're a proponent of GraphQL I'm criticizing your reasoning as unconvincing. Basically, Someone said GraphQL was bad, and your reasoning was all statements of the query "X is bad" should be dismissed.

I responded to explain to you why I didn't find your reasoning valid. That's all.

Default hostility to new concepts and frameworks can save a lot of time, energy and mistakes in software but sometimes for some use cases the new (variation of an old) solution can be superior.

We use it as the API we expose for our React and mobile clients and it's just, so good. I'd never want to consume it for a non-FE client but it's night and day versus stitching the results of multiple API calls together using some godawful chunk of mess like Redux.

We have a C# backend and Typescript frontend. We write our backend resolvers of the form `public async Task<SomeResultType> GetSomeNamedField(TypedParams pq)` and it just works, Apollo generates type safe client code and we define the schema in a single place. We still write backend code to implement each resolver method, exactly how we did in a normal API but... that's just the same.

I wonder how bad other backend devx must be for all these people to hate it, it seems more like a language specific implementation flaw than a genuine problem.

What I've noticed is people get their first taste of a type safe api and automatic client creation via GraphQL and don't understand that exists without it.

Perhaps we are talking about different kinds of "safety" or "aspects of safety"?

- Makes caching more challenging since there are now more possible permutations of the data depending on what query the client uses. A hacker could just spam your server's memory with cache entries by crafting many variations of queries.

- Makes access control a lot more complicated, slower and error-prone since the query needs to be analyzed in order to determine which resources are involved in any specific query in order for the server to decide whether to allow or block access to a resource. It's not like in REST where the request tells you exactly and precisely what resource the client wants to access.

- Adds overhead on the server side. It requires additional resources to process a query rather than just fetching resources by ID or fetching simple lists of resources. A lot of work may need to happen behind the scenes to fulfill a query and GraphQL hides this from the developer; this can lead to inefficient queries being used. I have a similar complaint about database ORMs which generate complex queries behind the scenes; this makes it difficult to identify performance issues in the underlying queries (since these are often completely hidden from the developer). Hiding necessary complexity is not a good idea... Maybe worse than adding unnecessary complexity.

You could use something like https://stellate.co/.

> - Makes access control a lot more complicated, slower and error-prone since the query needs to be analyzed in order to determine which resources are involved in any specific query in order for the server to decide whether to allow or block access to a resource.

Hasura and Postgraphile can do this - in the case of Postgraphile it obviously requires Postgres.

> It's not like in REST where the request tells you exactly and precisely what resource the client wants to access.

It can be. You can have a query that does `getObject(id: $id): Object`.

> Adds overhead on the server side.

Yep it pulls a heap of complexity around data fetching, synchronisation, and data modelling from the client to the server.

As it requires both the client and server to come to some agreement about a shared data model, it can appear as more work up front. But it enables a decoupling of the client and server such that the client can make requests for new use cases with the existing shared data model.

> No clear path for Api versioning

GraphQL came about as a way for mobile clients to call backend services. At Facebook, once a version (of th emobile app) was released, it was essentially out there forever. Some people would simply never upgrade until they absolutely had to.

So the point of GraphQL is that you want to get away from thinking about versioning your API and cleanly upgrading because you probably can't. You can do versions but you don't have clean divisions. You'll mark a given field as "since v2.1". And fields that you ahve added can basically never be removed. The best you can do is make them return null or an error.

So if you want to do versions it probably means you have control over the server and the client such that you can deploy them almost simultaneously. If so, GraphQL isn't really designed for your use case. If not, get out of the mindset that client and server versions can move in lockstep.

I will say I think GraphQL made one mistake and that's baking in string values into the API. You can't change a field name without breaking your API. Same with enum values.

Protocol buffers (including gRPC) instead went for numbering. The name is just a convenience for reading the IDL and data definitions and for code generation but it doesn't translate to the wire format at all.

This can have downsides too but they're fairly minimal. For example, if you accidentally renumber your enums by inserting a new value in the middle, the whole thing can break (side note: always explicitly number your enum values in protobuf! That should've been the only way to do it).

Another issue is that fragments seem like a good idea for code reuse but they can get really out of hand. It's so much easier just to add a field to an existing fragment. If that fragment is used in a bunch of places you may find yourself regenerating a ton of code. You will never be able to remove that field from the fragment once added.

Disclaimer: Ex-Facebooker.

This nails it. For distributed apps where a client might never be updated, you can't really change your schema if you want to guarantee that your app works for everyone. You can build in a mechanism to prompt users to update to a later version, though, and that can be very effective.

* Autogenerated documentation

* Autogenerated wrappers for scripting languages

* Autogenerated validator for requests and responses

For a REST API, you can get most of these things with swagger or stuff like that, but clearly it's an afterthought. If you have a schema, it's all much more natural and elegant.

But the most important thing you get with GraphQL is batching. For our use case (a decompilation pipeline) if you make 10 requests one after the other or 10 requests altogether it makes a huge difference in terms of performance.

If you need batching and design a REST API, for every nice endpoint you have you need to make a bulk version of the API. You're likely going to do that POST'ing a JSON. Now, once you're at that point, you're reinventing the wheel with six sides.

If your backend is in C/C++ and I suggest to make a C API for Python and use ariadne:

    https://ariadnegraphql.org/

Doesn't HTTP/2 make this mostly obsolete? One of its big features is request multiplexing.

Regarding the auto-generated code bit, are auto-generated GraphQL clients a thing? It seems like it would be doable, but I haven't found any (at least for the languages I'm using).

HTTP/2 helps with the network layer, but your backend will still handle requests one-by-one. Depending on what you need to do, this might make a hell of a difference.

> Regarding the auto-generated code bit, are auto-generated GraphQL clients a thing? It seems like it would be doable, but I haven't found any (at least for the languages I'm using).

There's this:

    https://www.graphql-code-generator.com/

When I built Joystick [1], this is why I implemented the API system [2] as a JSON-RPC model, but stole the idea of validating inputs (optionally) and then on the client, optionally specifying tailored output (also optional—like how you can request specific fields back in GraphQL but instead of a custom query language, just pass an array of paths like ['customers.creditCard.expirationMonth', 'customers.creditCard.expirationYear'] for the specific data you want returned).

What I learned implementing that is that the typing/querying for specific fields ideas is brilliant, but much better when it's flexible (i.e., I want it sometimes but not all the time).

[1] https://github.com/cheatcode/joystick

[2] https://github.com/cheatcode/joystick#api-1

I feel like this a false truth.

Most people are building a web app, or a mobile app and consuming an api and displaying all the data they retrieve.

If you have an rest api which returns an object with 6 properties. And a graphQl scheme which returns those same 6 properties. You’re not saving anything.

Now if you have a website and a mobile app, where the mobile app needs 3 fields and the website needs 6 fields. You will obviously save on bandwidth with the mobile app.

The problem here is most of us are not building Facebook. The data saved is peanuts and the bandwidth cost is probably going to be far less than the total cost of doing the work to support graphql.

For a company like Facebook which has many different integrations as well as 3rd parties integrating, graphql is obviously a godsend as integrators and integrations can consume only what they require and save Facebook millions of dollars in bandwidth.

In a REST paradigm you over fetch because not all of these variations need the same data, or you send less but then the clients thicker because they merge API calls and have divergent presentation logic, or you have a bajillion API versions.

There's often a lot of back and forth between the various teams for each rev of the API.

GraphQL lets the clients drive the definition of the data fetching. That's it.

95% of the criticism of GraphQL is people complaining that GraphQL doesn't solve the problem of preparing the API response for these different requests. While that's true, that's not what it's supposed to provide. Whether you have a REST API with 26 versions or a GraphQL API with 26 variations of query you're going to have to write a backend-for-frontend style service that resolves the results.

GraphQL just standardizes this process.

This problem is solved by quite a few GraphQL providers nowadays. Hasura, DGraph (not true graphql but close enough), Prisma. I like Hasura quite a lot for many projects. Just define your database and you instantly have a full GQL API for the clients to use however they please, no backend required really. Doesn’t work for everything, but it’s pretty great for a wide swath of projects.

You aren't thinking big enough. We have a graphql API where we have a bunch of enterprise users all wanting to pull out different types of data. They can decide what they want to get, and pull exactly that data. They want access to different tables, fields, and for different purposes and with different filters. We don't have to be involved, we just give them the schema.

But there's also the issue that some presentation and business logic is also provided by the graphql schema. Graphql knows which nodes connect, the db itself doesn't. And special cases like overrides, formatting, etc can be handled by the graphql server.

That’s a great use for graphql. My issue is toooo many people are building web apps with graphql where they are the only consumer. They are not getting any of the benefits of graphql, especially bandwidth savings.

If you have many people integrating and you in vision the types of integrations needing very different queries for data then graphql is great.

But most companies are a website, maybe some mobile stuff, and not enough traffic to warrant the complexity or benefits of graphql.

Not entirely true, as it allows you schemas to scale, but your requests to remain small.

For example a "User" record might have 30 fields, and it might have more as the system evolves. But your requests that only specify "User First name" will remain the same size.

What I like doing is to create a REST layer that sits just on top of the database, and a GraphQL layer on top of it that allows all kind of fancy queries. Yes, HTTP is slow and multiple calls for a single request should be avoided if possible. But it's much easier to run server-to-server HTTP calls (especially if the servers live in the same DC or physical machine) than running client-to-server requests.

> It doesn't support map/tables/dictionaries. This is actually huge. I get that there might be

It does. You can define, say, an "any" or "json" type in your schema and emit anything you want at a field with such a type. For example https://stackoverflow.com/a/63588485

> No clear path for Api versioning

Some options include:

- Prefixes (`/v1/graphql`, `/v2/graphql`)

- Backward compatibility: only adding and not subtracting things you want to support.

Lots of fair criticisms though. My two cents:

There are very few cases for starting a GraphQL based project by writing a GraphQL server (resolvers, queries, etc). This is where devs waste time instead of exploring their concepts. Instead, use GraphQL with something like Hasura that generates the GraphQL service for you based on database schema.

I generally disagree. While Hasura and the like can get you moving quickly, they let you cheat on designing your data model.

Ideally it’s a collaboration between all involved to develop a shared understanding of the domain, and the queries and mutations (how to read and write).

Where possible avoiding implementation details leaking into the schema will let you change those implementation details when needed.

If you auto-generate from a database, your database itself becomes your schema. This is rarely the best way to represent your data model in an API.

I've completely avoided it for years. If a potential new job contacts me and they use graphql, it's an immediate no from me. It's an immediate red flag that the engineering culture at the company is poorly run and would be a nightmare to work in.

Run away, as fast as possible.

Well, at least I'm glad I know I'll never be working with you!

I'm not giving you shit because you don't like GraphQL, I'm giving you shit because of your asinine "if you use GraphQL your company is poorly run and a nightmare" comment.

Whenever I see a comment from any developer that says "If you use technology X then you are an idiot", then I know that developer is either incredibly junior and doesn't understand the tradeoffs in choosing any technology, or they're showing typical "if you don't like what I like than you don't know what you're doing" arrogance that inevitably always makes it a pain in the ass to work with that person.

Needless to say, the VB app worked fine and became the product.

Huh? No no, on the contrary: Straightforward CRUD apps, that's exactly what VB was built for and excels at. Only Delphi is better.

The thing about "Visual" C++ is that it isn't (or at least wasn't, last I looked) really very visual at all. And that sucks for building simple in-house CRUD apps, where the VB / Delphi drag-and-drop UI builder paradigm is a huge productivity multiplier.

I wouldn't choose VB myself, but when it's between VB and C++ for simple data pushing, I would indeed choose VB.

Let's say it like this: if you need to move stuff, would you choose a F1 car or a minivan. I would pick the minivan.

If you were building an application that does little more than populate forms with data from a database and then update the database, VB was totally adequate. The most important part of the job was the DB and query design.

Today you'd probably just use browser-based UI.

Also if you've spent time in corporate development (rather than a software company), I think this scenario is a common one. If you show management a prototype that works, they're going to ask why we don't just make that the product. And if you don't have a good reason... you don't have a good reason.

The primary, inviolable value I have, and look for, in dev teams is "strong opinions, loosely held". Meaning I want to work with engineers that have the experience, motivation and intelligence to have strong opinions about how things should be done, but it's also critically important that developers are humble enough to know other developers may have other experiences that can inform why a different decision can be better.

If you've worked in a dev team that embodies this attitude, you know how great it can be and how dev team members will naturally work to strongly defend the group dynamic that it fosters. Meaning if a developer with a bit too much arrogance joins the team, they can often be trained into not having to be so judgemental, or making disagreements about real issues and not emotional arguments ("GraphQL sucks and you're stupid if you use it") If not, the existing team will quickly reject that arrogant developer because they know how dangerous they can be to a healthy group dynamic.

Rather strong opinions, not super-strongly held.

If you know you're somewhat flexible in your opinion, it's going to be quite strong, but not all that strong. OTOH, if you have an even somewhat strong opinion, it's no use letting yourself be swayed from it all that easily; make them advance quite a good argument for it first.

But then, depending on how heavily you load your adjectives, maybe that's what your (admittedly much more pithily put) version meant, too. I just wanted to put the modifiers out there lest someone read the maxim at its strongest.

Too many tech shops sabotage their culture and dozens of potentially great contributors in order to keep a few (or one) toxic contributors that the powers that be erroneously believe are irreplaceable.

Anyone can be a 10x developer when you sabotage the well-being and productivity of those around you.

React , imo, is a good over engineered library suffering from fragmentation. Angular is less fragmented, and Vue is the most elegant, performant and versatile of the 3. Good Devs choose Vue after having worked with both react and angular. React Dev never tried Vue, nor Angular Dev try React. Vue Dev usually know all 3.

Having a red flag like graphql can tell a lot about technical overview and experience in failure.

Graphql solves a caching issue that Facebook has. Makes the frontend team life easy, making the backend team life hell , big big hello. Scope changes in the backend are terrible.

Unless your team is engineered driven, and engineers take tech decision, and setup the sprints, going graphql in the backend is a recipe for disaster.

Solutions like Prisma, Hasura, and Postgraphile make GraphQL dead simple to implement compared to REST when exposing relational data.

AWS AppSync allows for a fully managed "serverless" experience as long as you're willing to do the schema creation grunt work and write Velocity templates. (FWIW, I'm not a fan, but it's still an option.)

Apollo (and Netflix DGS) are for when you're writing everything yourself, and you just need a simple API to tie in to the GraphQL spec in exchange for having to write/optimize/maintain it all.

The bright side to GraphQL is that you have choices, and when you present your "menu" of options, clients can grab what they need. Whereas on the REST side, any new requirements in calling requires direct interaction with the backend team and a new endpoint.

Honestly, server-based data access doesn't get any simpler than Postgraphile, but I totally see how you could get burned by an ill-fitting solution. However that is not GraphQL's fault. You might as well blame HTTP for problems you've had with Node/Express even though you've got other options in every programming language not to mention "pre-baked" solutions like Apache, Nginx, etc.

It's just a spec defining interaction, not a prescription for how that spec is implemented. It is also not a silver bullet. Right tool, right job, and all of that.

Most software engineers I’ve worked with have been incredibly humble and dedicated. The mythical bearded guy that showers three times a day, comes to the office with shorts and flip flops, and refuses to install Windows on the accountant person’s machine because it’s objectively bad is something I’ve only seen in memes and stories from older people I’ve worked with.

I personally think dissolving this myth, along with the one that programming is easy and / or none of us know what we’re doing, should be a shared goal between people who care about what they do and how others perceive it. Otherwise we’re unknowingly cultivating it into existence, and I definitely don’t want to work with arrogant, dogmatic developers.

When it's a junior, I remember myself and think they still need to learn.

When it's a senior, I know it's not a senior.

Says who, exactly? What data are you basing this on? Or is it a completely subjective opinion dictated by frustration likely caused by the lack of understanding of it?

> Or is it a completely subjective opinion dictated by frustration likely caused by the lack of understanding of it?

You can ask this this very same question when people say graphql is an amazing piece of software/paradigm, except s/frustration/hype/

And, in general, there's no such thing as a "good" or a "bad" technology, there are dimensions and each dimension is a spectrum: utility, adoption, availability, cost, complexity (although hard to determine), etc. to compress all that down to "hype" or "it sucks" just show how little time has been spent on understanding the nuances I mentioned above.

I don't claim GraphQL is amazing or even good, it just proved to be a great way to build APIs for the projects I worked on. I'm sure someone who builds firmwares for embedded automated plumbing systems would disagree (within that context). If you decide not to adopt it I just hope you do it after a rational, unbiased review of what the tech is capable of and what the shortcomings are, rather than "oh it's over hyped".

> Did you try reading the thread? What do you mean by data?

Please don't question whether someone read the thread or not (which is irrelevant within the scope of this discussion anyway) just because they disagree with you.

Great. What is your take on the postal service structure of Turkmenistan btw?

If many manage to use GraphQL and be content with it, that should be an indicator to you. But, you chose it isn't and that you'll merely display how politely negative you can be.

Thank you.

...I get it, the gql request did succeed, I've previously described it as like a 'layer 8' on top of HTTP: the problem being that all the tooling is for HTTP.

I wish 'REST' was one thing - with generated OpenAPI servers/clients & 'links' for example we could achieve what gql sets out to, if only there was a single way to do it.

Building on this are result types, where you can return a union with the intended type and something like AccessDenied for specific fields a user does have access to, but some other user might. Here you start to model the happy and unhappy paths of the data model.

GraphQL itself doesn’t really say anything about the network layer, it sits above that, in the application layer. You can run your queries and mutations over a websocket connection, at which point 200/4xx/5xx don’t make sense.

I'm not sure how that's a problem? The client knows where to look for errors: not in the http response code but in the JSON payload. Why is that an issue?

Backend to backend communication is almost never graphql (is that changing in a big way?) which would indicate the main reason for graphql in a client-server situation is data saving but at the cost of complexity and other downsides. Almost certainly the data savings in many cases is not worth it.

Oh and then you have things like Apollo having cache bugs that result in incident level problems.

Granted, it’s a problem to have to do that. But such is life with entity-level caching.

On the other hand, you tend to do "select * from FOO" and get more data from the db, because you don't know what the caller will ask for.

I don't think I've even seen a codebase filter the SQL based on the caller. I think I tried doing it once and it was a pita. (Please correct me if it's easy).

I still don't think I would personally recommend GraphQL to most companies.

I was honestly surprised by this: when I first heard about the idea behind GraphQL, I was certain that I'd pass in nested data structures.

I use it because I have to (external services jumped on the hype bandwagon), but I don't consider it significant progress. And this "save bandwidth" advantage is totally oversold, I really can't see how the savings can be significant in a practical way.

That's like saying SQL is crap because you need to build queries by hand. Conflating a protocol/spec with its implementation and/or the way it's used is not something a "very senior dev" should do (not questioning you personally, just the validity of what you wrote in this specific comment).

There are plenty of good GraphQL libraries that make writing queries/mutations and the whole schema a breeze. I've been using graphene for Python for a couple of years and, although it has some rough edges, it's actually pretty decent. And GraphQL is quite a good mental model to work with that both backend and frontend can share.

<rant>Honestly I'm getting tired of seeing these comments on HN, it's the same for Kubernetes or other technologies. Often written by someone who didn't take the time to actually study and understand the tech and use it for actual projects. Often with no data to back it up whatsoever. The quality of posts and comments here used to be a lot higher but it's slowly turning into a plaintext version of dev.to </rant>

And yes, SQL is "bad" because you write query strings. The funny bit is that GraphQL may be just as hard to model in a type-safe way as SQL is, if not a little harder. At least with SQL we have a reasonably good way to model it with methods (see LINQ). LINQ was built 15 years ago, so this problem was well understood back then.

Says me, and also any other person that has tried to build a type-safe GraphQL query builder

> Consumers of the APIs I work on are mostly written in Typescript and constructing types based on the GraphQL schema is a completely automated process

Constructing "types" of what kind, and in what way? Types for queries? Do you need to rerun the tool every time you modify any of your queries? Does it need to watch your query strings to generate the right types for them?

> Ok then every single language is bad because every language's syntax is based on (conceptually) constructing strings. I don't get your point.

Instead of arguing, why not look at what LINQ does?

For the best experience, you should probably try them with an editor/compiler: https://github.com/dotnet/try-samples#basics

Examples: https://www.c-sharpcorner.com/article/writing-complex-querie...

The hard bit here is making sure the language type-checker is fully aware of the involved types, both while writing the query as well as while selecting the results to be returned

This approach has since been copied in more capable languages. One of my favorite examples lately is Rust's Diesel: https://diesel.rs/ (see the "complex queries") example.

A query language designer aware of the above lessons learned with SQL might take special care to ensure their new query language is easier to model in existing languages. For example, they might consider an alternative OOP or FP based syntax, or to generalize they might put some thought into what would make it easy to write a type-safe query builder. After all, while SQL was developed in 197x and we had a different model for data access early on (stored procedures instead of flexible language-integrated queries) so its easier to understand that we didn't consider integration with other languags. TypeScript already did exist when GraphQL first appeared in 2015, and it's been 7 years of LINQ at that point.

Yet, we still went the stored procedures route. Tools such as graphql-codegen [1] require you to regenerate your types every time you edit your query strings

[1]: https://www.graphql-code-generator.com/

At this point I'm pretty sure you're conflating the underlying technology with what a wrapper could do on top of it. And in that regard I absolutely agree with you: raw GraphQL doesn't make any sense, the same way raw SQL (in 2022) doesn't make sense either.

EDIT (mandatory before I get lynched lol): except in cases where the wrapper builds a query that is inefficient or should be tweaked manually.