If you open it up for any possible query, then give that to uncontrolled clients, it’s a recipe for disaster.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Guides/Ran...

I would be surprised to see many (or any) GQL endpoints in systems with significant complexity and scale that allow completely arbitrary requests.

With typed languages you can auto-generate OpenAPI schemas from your code.

I could be wrong but I thought GraphQL's point of difference from a blind proxy was that it was flexible.

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 a way to transmit a program from client to server. It then executes that program on the server side.

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.

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.

2 years ago I gave a talk on Vector DB's and LLM use.

https://www.youtube.com/watch?v=U_g06VqdKUc

TLDR but it shows how you could teach an LLM your GraphQL query language to let it selectively load context into what were very small context windows at the time.

After that the MCP specification came out. Which from my vantage point is a poor and half implemented version of what GraphQL already is.

> I strongly believe it is one of the best technologies for AI agents

Do you have any quantitative evidence to support this?

Sincere question. I feel it would add some much needed credibility in a space where many folks are abusing the hype wave and low key shilling their products with vibes instead of rigor.

Agents should be calling one level of abstraction higher.

Eg calling a function to “find me relevant events in this city according to this users preferences” instead of “list all events in this city”.

IMO the biggest pain points of graphql are authorization/rate limiting, caching, and mutations... But for selective context loading none of those matter actually. Pretty cool!

I have had the best luck with hand-crafted tools that pre-digest your API so you don't have to waste tokens or deal with context rot bugs.

Keep in mind that all LLMs are trained on many GraphQL examples because the technology has been in existence since 2015. While anything custom might just work it is certainly not part of the model training set unless you fine-tune.

So yes, if I need to decide on formats I will go for GraphQL, SQL and Markdown.

how is that going to work with my use case, do a web search, do a local api call, do a graphql search, do an integration with slack, do a message etc..

Since most of the ontologies I'm using are public, I just have to namedrop them in prompt; no schemas and little structure introspection needed. At worst, it can just walk and dump triples to figure out structure; it's all RDF triples and URIs.

One nice property: using structured outputs, you can constrain outputs of certain queries to only generate valid RDF to avoid syntax errors. Probably can do similar stuff with GraphQL.

I expect you could achieve the same with a comprehensive OpenAPI specification. If you want something a bit stricter I guess SOAP would work too, LLMs love XML after all.

Being AI-first means we are naturally aligned with that kind of structured documentation. It helps both humans and robots.