Now imagine an API that turns every prompt into a validated query within seconds, no prior schema knowledge required because we're building an index, so the model is not wasting tokens on that task even with multiple megabytes of SDL.
We're building such an API for some of the biggest enterprises in the world. Many of them have very large (federated) GraphQL APIs across tens and hundreds of teams. From an agent perspective it's a lot easier to consume a single unified graph where a single query can span 5 relationships vs making hundreds of N+1 rest API calls across many heterogenous APIs from different teams that all look slightly different.
I did something that surprised myself. I always thought that people are right in saying that GraphQL breaks HTTP caching, but I never deeply analyzed if that's actually true because so many people say the same thing. So I analyzed this and many other claims and was surprised to find out that almost every claim comparing REST vs GraphQL is either wrong or misleading.
We need to stop calling N+1 a GraphQL problem when it's simply an API problem (and REST has it at the HTTP layer while GraphQL has it as the resolver layer, which is actually an advantage for GraphQL, but people typically picture it differently). Anyways, this post tries a scientific/research-driven approach in the hopes to combat the AI slop that makes bad claims about GraphQL.
GraphQL is a really powerful query language, Fragments are extremely powerful, and the ecosystem is very healthy with multiple vendors and developments like oneOf directive, defer, etc.
There are a lot of tools already that do local speech-to-text, but none of them allowed me to "select" code/text in a file and then paste a reference to my selected code together with the transcript.
I wanted this to work locally and I wanted it to work independently of the IDE (because I'm using multiple). I also wanted it to work with any coding agent (Claude, Codex, OpenCode).
So I put together parakeet & ripgrep in a Rust tauri app. It works perfectly for me and I'm using it every day whenever I'm coding. Maybe it's also useful for others.
Nice stuff. I keep wanting to be more speech oriented but it's been hard to get myself to move to that. I like how you use the accessibility APIs to get data out; that feels like such crucial leverage point for expanding agency!
> When you press the hotkey, macOS Accessibility APIs read the selected text and line numbers from the active editor window. If the Accessibility API doesn't return selected text (some apps don't support it), Voxcode falls back to simulating Cmd+C.
Regarding working with code, I've quite enjoyed using the mcp-neovim-server. Asking it to show & select pertinent lines can be helpful, especially when there's multiple file references at once. Turning this around & asking the LLM to get data out would be possible, but as you say, this would be IDE specific. Ideally there would be some good cross-IDE MCP tools.
https://github.com/bigcodegen/mcp-neovim-server
One thing I find interesting is how GraphQL has evolved from an API technology for API consumers with "different needs" to an API technology for agents. What helped organizations scale GraphQL across multiple teams is Federation, a way to split one supergraph into multiple subgraphs. So, what works well to scale teams actually works equally well for agents. The core value you can get from Federation is a "coordination" layer that is deterministic. Now, what's interesting is that you can scale agentic software development pretty well when you have a deterministic layer where everyone involved can agree. I wrote more about this on our blog if anyone is interested: https://wundergraph.com/blog/graphql-api-layer-for-ai-agents
I think of "Federation" as aggregating content from disparate in-situ sources into a common index under a consistent schema. I agree that schema is good, am always tempted by big schema, and seem to always settle for task-specific schema with mappings between schemas strictly as necessary. LLM's seem nice for schema to schema mapping and supernice for binding entities from unstructured sources into schema. But overall I feel it is pointless to talk about structure without talking about hydration - about binding and mapping. Do you see that as "solved"?
The problem with this article is that GraphQL has become much more an enterprise solution over the last few years than a non enterprise one. Even though the general public opinion of X and HN seems to be that GraphQL has negative ROI, it's actually growing strongly in the enterprise API management segment.
GraphQL, in combination with GraphQL has become the new standard for orchestrating Microservices APIs and the development of AI and LLMs gives it even another push as MCP is just another BFF and that's the sweet spot of GraphQL.
Side note, I'm not even defending GraphQL here, it's just about facts if we're looking at who's using and adopting GraphQL. If you look around, from Meta to Airbnb, Uber, Reddit or Booking.com, Atlassian or Monday, GitHub or Gitlab, all these services use GraphQL successfully and these days, banks are adopting it to modernize API access to their Mainframe, SOAP and proprietary RPC APIs.
How do I know you might say? I'm working with WunderGraph (https://wundergraph.com/), one of the most innovative vendors in the market and we're talking to enterprise every day. We've just came home from API days Paris and besides AI and LLMs, everyone in the enterprise is talking about API design, governance and collaboration, which is where GraphQL Federation is very strong and the ecosystem is very mature.
Posts like this are super harmful for the API ecosystem because they come from inexperience and lack of knowledge.
GraphQL can solve over fetching but that's not the reason why enterprises adopt it. GraphQL Federation solves a people problem, not a technical one. It helps orgs scale and govern APIs across a large number of teams and services.
Just recently there was a post here on HN about the problems with dependencies between Microservices, a problem that GraphQL Federation solves very elegantly with the @requires directive.
One thing I've learned over the years is that people who complain about GraphQL are typically not working in the enterprise, and those who use the query language successfully don't usually post on social media about it. It's a tool in the API tool belt besides others like Open API and Kafka. Just go to an API conference and ask what people use.
I'm with WunderGraph, a vendor providing enterprise tooling for GraphQL.
First, I absolutely love Capn Proto and the ideas of chaining calls on objects. It's amazing to see what's possible with CapNweb.
However, one of the examples compares it to GraphQL, which I think falls a bit short of how enterprises use the Query language in real life.
First, like others mentioned, you'll have N+1 problems for nested lists. That is, if we call comments() on each post and author() on each comment, we absolutely don't want to have one individual call per nested object. In GraphQL, with the data loader pattern, this is just 3 calls.
Second, there's also an element of security. Advanced GraphQL gateways like WunderGraph's are capable of implementing fine grained rate limiting that prevent a client to ask for too much data. With this RPC object calling style, we don't have a notion of "Query Plans", so we cannot statically analyze a combination of API calls and estimate the cost before executing them.
Lastly, GraphQL these days is mostly used with Federation. That means a single client talks to a Gateway (e.g. WunderGraph's Cosmo Router) and the Router distributed the calls efficiently across many sub services (Subgraphs) with a query planner that finds the optimal way to load information from multiple services. While capNweb looks amazing, the reality is that a client would have to talk to many services.
Which brings me to my last point. Instead of Going the capNweb vs GraphQL route, I'd think more about how the two can work together. What if a client could use CapNweb to talk to a Federation Router that allows it to interact with entities, the object definitions in a GraphQL Federation system.
I think this is really worth exploring. Not going against other API styles but trying to combine the strengths.
> First, like others mentioned, you'll have N+1 problems for nested lists. That is, if we call comments() on each post and author() on each comment, we absolutely don't want to have one individual call per nested object. In GraphQL, with the data loader pattern, this is just 3 calls.
Why is that a problem? As far as I can tell, those calls are all done on the server, where they're cheap normal function calls, and the results are all sent back with 1 roundtrip; because of the pipelining.
Because they each result in round-trips and individual queries to the database rather than a more efficient single round-trip with a join. Note: I don't know the details of GraphQL, but I'm assuming it does the smarter thing.
In this paradigm, the places where you are calling map() could probably be replaced with explicit getComments() or getCommentsWithAuthors() or two methods that do just one query each.
But you are right that this won't work great with traditional databases without significantly more magic on the server side, and in that sense the comparison with GraphQL is... aggressive :)
It is still much better than making all the calls client-side, of course. And there are many use cases where you're not querying a database.
And maybe there can be some fusion between GraphQL server infrastructure and this RPC-oriented syntax that gives people the best of both worlds?
Side note, a lot of people these days build agents on top of APIs. GraphQL has selection sets, which allows you to select subsets of objects. This is quite handy when it comes to gents because of context window limitations.
Could I use this to iterate over my AI generated code until it's not detectable anymore? So essentially the moment you publish this tool it stops working?
This is what GraphQL was designed for. Only select fields you really need. We've built an OSS Gateway that turns a collection of GraphQL queries into an MCP server to make this simple: https://wundergraph.com/mcp-gateway
The way we've solved this in our MCP gateway (OSS) is that the user first needs to authenticate against our gateway, e.g. by creating a valid JWT with their identity provider, which will be validated using JWKS. Now when they use a tool, they must send their JWT, so the LLM always acts in their behalf. This supports multiple tenants out of the box. (https://wundergraph.com/mcp-gateway)
We're building such an API for some of the biggest enterprises in the world. Many of them have very large (federated) GraphQL APIs across tens and hundreds of teams. From an agent perspective it's a lot easier to consume a single unified graph where a single query can span 5 relationships vs making hundreds of N+1 rest API calls across many heterogenous APIs from different teams that all look slightly different.
reply