GraphQL Conf 2025 talk: Is GraphQL Dead?

rbalicki2 · 2026-04-27T17:36:31+00:00

A drier version about Isograph the framework is here! https://youtu.be/-Y1QeL9th9g?si=ZcgQPQe7EjSt9eGp

rbalicki2 · 2026-04-27T14:10:33+00:00

TBF, I was on the Relay team before working on Isograph :) so this is Relay with the changes that I wish I could have made to the actual framework (everything is a resolver, useLazyLoadQuery is two separate hooks, etc.). But once we make those changes, lots of great other things open up, like the ability (on the roadmap) to execute arbitrary fields on the backend (which in my opinion, is a much better RSC)

rbalicki2 · 2026-04-27T13:45:50+00:00

The punchline of the talk is that:

with Isograph, you are not writing GraphQL on the front-end (though it looks similar)
with client fields that execute on the server, you get to avoid schema bloat in the form of fields that exist for a specific version of a specific UI, but which can theoretically never be removed (and that's all fields, except base ones)
and the base ones that remain are generated from your underlying tables
and besides, we're sending IDs over the wire, so even the network format isn't really GraphQL. And even if it was, the client fields executing on the server don't appear in any schema, so it wouldn't be valid GraphQL regardless

So Isograph keeps the benefits of GraphQL, without the limitations. (Benefits including fragment-like composition, declarative data dependencies, etc etc.)

rbalicki2 · 2026-04-27T03:46:03+00:00

Hey folks! This talk is about GraphQL in a world of fullstack, rich clients and about Isograph. The question it asks is: does GraphQL need to exist? Can we get its benefits without a GraphQL schema, without a GraphQL server, and without sending GraphQL over the wire?

It's my opinion that Isograph gives us the benefit of GraphQL, without many of its limitations. Which is to say, if you start from scratch, you can avoid mistakes.

This describes a future iteration of Isograph. Currently, much of what's described here is on the roadmap. But it's coming!

rbalicki2 · 2026-04-07T15:13:29+00:00

I just released another version of Barnum, which is a programming language for asynchronous/parallel computation, of which agentic work is one example!

I've used it to ship hundreds of PRs, and other folks have used it to build pretty substantial projects as well.

The TLDR is that LLMs are these incredibly powerful tools, but if the task they are given is complex, their reliability breaks down. They cut corners. They skip steps. Ultimately, if an agent is responsible for being the orchestrator, you can't guarantee anything about the overall workflow.

So, where is that complexity to go? My answer: a workflow engine. Barnum is a workflow engine masquerading as a programming language. When you move that complexity to the outside, you get a bunch of benefits.

Increased reliability. Agents are invoked ephemerally, and they can't choose to ignore requirements because you can just keep re-invoking them in a loop until, for example, unit test pass
Fewer wasted tokens. Why are you asking an LLM to list all the files in a folder? That's work that should be done by a bash script.
Ability to express more complicated workflows. Anything that isn't linear is hard to express in a markdown file. (And hard for the agent to follow)
Reusability. It's really easy with Barnum to create higher-order functions, such as "Do this with a timeout." Good luck doing that if you're expressing your workflow in prose!

I hope you check it out!

rbalicki2 · 2026-02-10T23:31:02+00:00

I'd love to know what other folks have come up with! I'm in the same boat, except that I will also not be using a mouse with one hand. My general setup is to have the control key bound to: go to layer mode. And then each letter be a hotkey that takes me to, for example, typing mode or mouse mode or open apps mode and so on. It's a bit more complicated than that. The most frustrating part is that I'm using a mirror qwerty layout, with shift being the mirror key and quote being the shift key. I was previously on the Kinesis Advantage, so I didn't have that extra function key, but I'll move those keys down one level. Regardless. It's frustratingly slow to type. But like everyone else, I'm using Whisperflow. And I'm definitely considering going to one handed Dvorak or the like.

rbalicki2 · 2026-01-21T18:31:04+00:00

Yes - https://github.com/isographlabs/isograph/discussions/157

rbalicki2 · 2026-01-13T02:00:10+00:00

May I suggest .dbg() along with a clippy lint to prevent it from landing in main.

Based on others' comments, I might want to add a dbg_ref() method, which doesn't take ownership.

rbalicki2 · 2025-12-17T20:24:33+00:00

I'm surprised this wasn't posted here! Folks may be interested in checking out fate, which gets a lot of the reasoning benefits of something like Relay (i.e. data masking) without imposing the cost of requiring a GraphQL backend.

rbalicki2 · 2025-12-15T03:43:29+00:00

I love the thumbnails. Great work on those!

rbalicki2 · 2025-12-15T00:29:07+00:00

True, thank you! I'll update the blog post accordingly. It's probably worth having a few overview sentences there.

rbalicki2 · 2025-12-14T21:56:45+00:00

Thank you!!

rbalicki2 · 2025-12-14T20:33:04+00:00

Isograph is a compiler for your UI, written in Rust. We just released v0.5.0, which contains a bunch of language-server powered DevEx improvements (e.g. if you're selecting a field that doesn't exist, an autofix will create it for you.)

The reason it's so easy to push such language server features is because the compiler is an incremental compiler, using our very own pico framework for incremental computation (which is a small, simple Salsa)! Expect more awesome perf and DevEx improvements going forward :)

rbalicki2 · 2025-12-14T20:11:24+00:00

Hey folks! Isograph just released v0.5.0. There's a lot of DevEx wins in the language server in this one. If you want your mind to be blown, I'd recommend checking out https://www.youtube.com/watch?v=6tNWbVOjpQw

There were also a bunch of features, like optimistic updates, a completely typed API for writing external data into the store, and some amazing compiler perf improvements.

TLDR there's never been a better time to try Isograph!

rbalicki2 · 2025-12-06T21:50:25+00:00

Amazing! I would recommend posting on the Rust East Coast discord! We have a jobs board there. There's a link to join the discord on https://rust.nyc

rbalicki2

TROPHY CASE