Podcast Summary: Rethinking GraphQL Frontends with Robert Balicki
Podcast: Software Engineering Daily
Date: September 23, 2025
Host: Gregor Vand
Guest: Robert Bellicki, Staff Software Engineer at Pinterest, ex-Relay team at Meta, creator of Isograph
Episode Overview
This episode focuses on the challenges and solutions in managing GraphQL data in modern frontend applications. The conversation centers on Isograph, a new framework developed by Robert Bellicki, its relationship to GraphQL and Relay, and novel concepts for improving performance, maintainability, and developer experience. Robert shares insights from his background at Meta (Relay team), his current work at Pinterest, and the philosophy behind Isograph.
Key Discussion Points and Insights
1. Robert’s Background and Motivation for Isograph
- Robert’s Journey (02:08): Formerly on Meta's Relay team, now at Pinterest helping adopt Relay. Created Smithy (React-like UI in Rust) and other UIs focused on reducing developer errors.
- Core Motivation: Building UIs and frameworks that help developers “not shoot themselves in the foot”—making correctness and efficiency the default.
“I sort of want to help people build UIs where they can't shoot themselves in the foot. And I know that that's a very niche thing to want, but I guess that's where I ended up.”
—Robert Bellicki [02:08]
2. The Isograph Approach: Problems Solved and Innovations
The Problem with GraphQL Data Fetching
- Traditional Issue: Managing queries in large apps becomes problematic—overfetching/underfetching, duplicating fields, coordination headaches.
- Manual query maintenance leads to unstable or bloated apps as requirements shift.
Isograph’s Solution and Philosophy (04:52)
- Component-Driven Data Declarations: Each component declares its exact data needs via "client fields".
- Build-Time Compilation: A compiler traverses the component tree and stitches together a query that fetches exactly the required data for the entire screen—no more, no less.
- Impact: Drastically reduces coordination overhead for developers. Local changes are safe and maintainable.
“With isograph, every component in this tree... declares the fields that they end up using. Then there's a compiler that runs at build time... and generates a query that selects just the fields that are used by this entire component tree.”
—Robert Bellicki [04:52]
3. Overfetching, Underfetching, and Data Masking
Definitions and the Core Challenge (08:57)
- Overfetching: Fetching more data than needed, straining backend resources.
- Underfetching: Not fetching enough; could break the UI or force inefficient subcomponent requests.
- Difficulty arises as component requirements shift—manual maintenance is error-prone.
How Isograph Addresses This
- Automatic Query Sync: No manual updates—data needs and query generation are directly connected.
- Data Masking: Each component only receives the data it explicitly asks for. Prevents bugs from accidental overexposure of data structure.
“Data masking is essentially the idea that each of these sub components, they don't receive that entire blog object that we received from the network. Instead, they receive just the fields that they specifically asked for... it eliminates this entire class of bugs.”
—Robert Bellicki [12:08]
- Significance for Developer Experience: Encourages stability and scalable collaboration, reduces accidental cross-component dependencies.
4. The “Client Field” Innovation and Comparison to Fragments
What are Client Fields? (15:00)
- Core Unit in Isograph: Like GraphQL fragments but not actual GraphQL. They are functions that take data and return a value (usually a React component).
- Composition: Components select and pass client fields down, forming a clear dependency tree.
Advantages
- No more fragment spreads, fragment references, or complex imports.
- Optimized Code-Splitting: Because the data and component code are linked at compile time, Isograph can defer loading both data and JS for subcomponents until actually needed.
“In isograph, because the client field is both the function and the data that it needs sort of packaged together... the compiler can be smart... and not include the JavaScript for the comment list in the parent bundle.”
—Robert Bellicki [15:00]
5. Performance: Code Splitting and Dynamic Loading
Tactics Enabled by Isograph (19:35)
- Split by Component or Data Shape: For highly dynamic apps (e.g., newsfeeds), only JavaScript and data strictly needed are loaded as the user interacts.
- Fine-Grained Async Loading: E.g., only load the JavaScript for a rarely used modal or a specific type of newsfeed item when it’s encountered.
- Ultimate Goal: Only fetch new data/JS not already loaded by other components.
“You can imagine a list of newsfeed items and the first time that we encounter a text-based post, well that's when we fetch the JavaScript for the text based component renderer...”
—Robert Bellicki [19:35]
Real-World Use Case: E-Commerce (24:12)
- Navigation between product list and detail could leverage Isograph to avoid redundant data fetches between related screens.
- Demonstrated power for real-world, large, and variable frontends.
6. Developer Experience and Tooling
Debugging, Language Server, and Reusability (25:26)
- Incremental Compiler in Progress: To support language server features (intellisense, go-to definition, auto-fix suggestions).
- Component Discovery: Plans for autocompleting and surfacing reusable components—reducing duplication (e.g., multiple avatar components).
- Feedback: Early users (e.g., Content Foundry) report a positive experience.
“Right now, a big project that we're working on is rewriting the compiler to be incremental... The next thing after that is to build out a language server. So the idea... is you're essentially able to do everything you want from within VS code...”
—Robert Bellicki [25:26]
7. Open Source and Community Involvement
- Project State: Still small enough for major new contributors to make significant impact; detailed public roadmap.
- Invitation: Join Discord, contribute ideas or code, or simply try Isograph and give feedback.
8. Relay vs Isograph: Choosing the Right Tool (31:30)
- Relay: Very mature, no performance compromises, excellent for large teams, but known for a tough learning curve and friction at adoption.
- Isograph: Targeted at high developer velocity, smoother DX, and local reasoning; still early but battle-tested by at least one real company.
- Recommendation: Great for greenfield projects, large teams, or anyone prioritizing developer experience and scalable architecture.
“Now is a really great time to adopt iGraph... The best users... are folks who are really, really into good developer experience and also large companies.”
—Robert Bellicki [31:30]
9. Looking Forward: Stack Support and Extensibility (33:14)
- Query Language Agnosticism: GraphQL today, but designed to potentially target SQL, gRPC, etc., with adapters.
- Frontend Flexibility: Isograph’s React coupling is minimal—can extend to Vue, Svelte, Swift, and Kotlin in the future.
“... we can generate different queries that we end up sending to the backend. Secondly, the generated files, they're basically JSON objects... that's certainly doable in any other language.”
—Robert Bellicki [33:27]
10. Closing Reflections: Motivation and Persistence (35:51)
- Where Robert Finds Energy: Mix of inherent enjoyment (puzzle-solving), frustration with the current state of tools, and now, seeing users benefit from his work.
- Transitioning Motivation: Frustration-driven at first, now joy from seeing others succeed.
“I feel like that frustration really drives me... recently now that Content Foundry is really using isograph... seeing somebody else get joy out of using what I've worked on for, you know, a couple years now is just kind of amazing.”
—Robert Bellicki [35:51]
Notable Quotes & Memorable Moments
-
On preventing developer pain:
“I want to provide a better experience. I want to have a better experience for myself. And I think that a lot of times, like when something isn't working quite right, it just fills me with sort of a righteous anger, I guess that keeps me going.”
—Robert Bellicki [35:51] -
On the importance of data masking:
“I don't know how anybody in the year 2025 is satisfied with building an app that doesn't have data masking. It doesn't scale to any number of developers, more than one.”
—Robert Bellicki [12:08] -
On the architectural vision:
“In isograph, because the client field is both the function and the data that it needs sort of packaged together, the ICE Graph compiler can be smart...”
—Robert Bellicki [15:00]
Timestamps for Key Segments
- Robert’s background and Pre-Isograph projects — [02:08]
- Isograph motivations and overview — [04:52]
- Problem of overfetching/underfetching — [08:57]
- Data masking explained and its significance — [12:08]
- Client fields as Isograph’s unique unit — [15:00]
- Performance via dynamic JS/data loading — [19:35]
- Developer experience, language servers, future tooling — [25:26]
- Community and contribution invitations — [28:05]
- Relay vs Isograph: adoption advice — [31:30]
- Roadmap and cross-platform vision — [33:14]
- Robert’s motivation and ‘righteous anger’ — [35:51]
Conclusion
This episode dives deeply into the architectural problems of GraphQL-driven frontends and how Isograph offers a principled, developer-friendly solution. Through client fields, automated query generation, and novel approaches to data and JS code-splitting, Isograph aims to deliver performance and maintainability without sacrificing developer experience. Robert’s passion combines technical depth with a refreshing focus on real developer pain, making this a must-listen for anyone designing data-rich modern frontends.
Resources: