jensneuse

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.

What problem does it solve? The hero of the website doesn't answer.

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.

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

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.

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.

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.

- https://wundergraph.com/

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)

I think they removed arenas again.

Let's say you have constantly 1k requests per second and for each request, you need one buffer, each 1 MiB. That means you have 1 GiB in the pool. Without a pool, there's a high likelihood that you're using less. Why? Because in reality, most requests need a 1 MiB buffer but SOME require a 5 MiB buffer. As such, your pool grows over time as you don't have control over the distribution of the size of the pool items.

So, if you have predictable object sizes, the pool will stay flat. If the workloads are random, you have a new problem because, like in this scenario, your pool grows 5x more.

You can solve this problem. E.g. you can only give back items into the pool that are small enough. Alternatively, you could have a small pool and a big pool, but now you're playing cat and mouse.

In such a scenario, it could also work to simply allocate and use GC to clean up. Then you don't have to worry about memory and the lifetime of objects, which makes your code much simpler to read and reason about.

You can often fool yourself by using sync.Pool. pprof looks great because no allocs in benchmarks but memory usage goes through the roof. It's important to measure real world benefits, if any, and not just synthetic benchmarks.

Is this a modern version of CGI with process isolation?

We wrote a breadth first algorithm to handle the second problem you're describing. I'm curious to hear your thought on it: https://wundergraph.com/blog/dataloader_3_0_breadth_first_da...

Short answer:

gRPC is widely understood as an API tool for Microservices. Microservices solve an organizational problem, not a technical one. Ironically, gRPC doesn't really help to solve the organizational problem.

However, GraphQL in combination with Federation, also known as GraphQL Federation actually DOES help organizations to scale APIs across teams and services.

So, even though the typical popular opinion suggests that gRPC is better for Microservices than GraphQL, the reality looks different.

There were times when it was popular to generate a GraphQL API from your database but that's not how the query language is used today.

GraphQL is a query language to implement query style APIs. These days, it's most widely used as a "Federation" layer to expose a single query-able graph on top of a (micro-) service architecture.

I absolutely love Postgres, but please allow me to say that you absolutely don't want to expose an API generated from a database to people outside of your team. This limits you a lot in changing the way you store your data.

I wrote about this topic before and haven't changed my opinion much. You don't want to have that tight coupling: https://wundergraph.com/blog/six-year-graphql-recap#generate...

Looks cool and I understand what it does. Can you explain the production use case for this solution? It's not clear to me how this would be used in real life.

I'd argue that a lot of people are moving from Kafka to NATS. NATS and Kafka serve different purposes and for many use cases related to APIs, NATS has a lot more to offer, like like wildcard topic topologies.

I'd like to add that I'm seeing more and more companies unifying synchronous and asynchronous APIs. With the concept of GraphQL Federation, it's possible to "extend" Entities by defining their (primary) keys in a GraphQL Schema. If we're combining this with Async APIs, e.g. NATS or Kafka, we can enable teams to build APIs around events, while still being able to distribute the implementation of how certain fields can be resolved. The Federation Router then joins the Stream with additional data from synchronous services, a very powerful pattern I believe. I wrote a bit more on the topic here: https://wundergraph.com/blog/distributed_graphql_subscriptio...

Disclaimer, I'm one of the authors of an open source project to implement GraphQL Federation (https://github.com/wundergraph/cosmo).

GraphQL, but more specifically GraphQL Federation solves an organisational problem. With Federation, teams can collaborate on building an API together with a Schema Registry and Composition Checks across all Subgraphs (Services), which is a unique enabler in the market.

We've got a lot of customers in the enterprise segment and it's growing rapidly to the point where I'd say it's becoming an enterprise standard.

As a founder with multiple years of experience I can say that this post and a lot of other comments are coming from people who don't understand the life of a founder. It's not so much about risk. My peers earn 5-10x my salary. I'm paying my employees more than myself. I have to provide for 3 kids and we have a lot of debt on the house. I'm working day and night, 24/7. I don't like the phrase "taking money off the table". If I can sell some equity, this is none of your business. I started this company with my co-founders. Start your own company and try reaching Series A. It's almost impossible. Most people are not capable of getting there.

Thanks for posting!

If you're open to it, we could collaborate on a demo of the two components, PeerDB CDC and EDFS, and work together on cross promoting the solutions. We've got a large customer base in the enterprise segment that's interested in EDFS with Kafka, and I think that your solution fits very well into the picture.

If you're interested, just fill our contact form and mention this thread. This could be really cool!

We're currently in the process of adding Kafka support to EDFS (Event Driven Federated Subscriptions), a specification to add NATS, Kafka, and other pub sub or streaming services to a federated graph.

There's one thing missing and we could hook it up to your CDC solution. For each message, we need to set the __typename field. Does your solution have a way to accomplish this?

EDFS reference: https://cosmo-docs.wundergraph.com/router/event-driven-feder...

Sounds similar to a technique we're using to dynamically aggregate and transform JSON. We call this package "astjson" as we're doing operations like "walking" through the JSON or "merging" fields at the AST level. We wrote about the topic and how it helped us to improve the performance of our API gateway written in Go, which makes heavy use of JSON aggregations: https://wundergraph.com/blog/astjson_high_performance_json_t...

At the very beginning, I was a solo founder and put my project WunderGraph (https://github.com/wundergraph/cosmo) on GitHub.

After a while, a CTO contacted me and asked if I could "support" his team and add some features that he wanted. After a month of sweating, we agreed that they'd pay me a monthly support subscription of $2k.

I learned a lot from the use cases, improved the software, and got some more users, which ultimately was enough of a story for VCs to raise a $3M seed round, which I think is quite cool as a first-time founder from Germany with zero connections, no YC friends, etc...

I quickly realized that I could not pull this off alone, so I teamed up with 3 fantastic Co-Founders who are responsible for the business side, marketing, sales, and engineering.

Fast forward two years and we're growing our customer base at a great pace and are slowly looking towards a Series A. I can tell though that the way from our first customer to where we are now was extremely tough. We're in enterprise sales, we had to switch our strategy at some point. Lots of learning, lots of pain.

In retrospect, I wouldn't say that the first customer is the hardest. Building a repeatable sales motion is much harder. Building a product, marketing, and sales process that all aligns well for repeatable sales is a lot of work.

Whoever tries this, good luck and please connect if you need help as a founder or want some advice. I love to help others to start their own business. It's hard, but it's also a life that I don't want to miss.

Say it 5 times and a genie appears who creates you a federated Graph of 100 Microservices although a single boring monolith would have been enough.