A New Paradigm: How Do I Optimally Break my UI Into Queries?
summary
Shows a concrete tradeoff: attaching one query per tiny component produced UI and schema bloat (example: 607 components on one page, duplicated review and carousel components across product lines), while one-query-per-screen enabled server-driven layouts but exploded AST size from 193,000 to 700,000 lines (10MB to 47MB) and slowed responses from 8s to 30s. Proposes attaching queries to design-system pattern components, using task modeling to define them, and an “experience container” to batch queries; also cites ~5,000 schema types and a one‑year slowest‑upgrade constraint.
AI-written summary · about
chapters (8)
- 0:00Introduction and context
- 3:11Component complexity on UI pages
- 10:35Design system hierarchy explained
- 15:10First use case and its flaws
- 17:19Second use case and performance issues
- 20:33Theories for optimal query scoping
- 26:28Experience container concept
- 28:12Key takeaways and closing
related talks
01h 00mArchitecting Data-Driven Apps for UX Success
35mModular Quasar:Reducing Cognitive Overhead In Large Applications
32m6 App building patterns your Seniors didn't want to know
14mQA
25mThe Power of Strongly Coupled GraphQL Queries for Internal APIs
20mA framework for building data driven interactive front ends
52mResponsive Web Applications with Container Queries
49mKeynote: Best Practices – UI, API and Server-side