Introduction and Early Skepticism 00:00
- Initially skeptical about Convex, considering it only suitable for toy apps and beginners
- Originally preferred modular, swappable tools in the backend, drawing inspiration from prior web stacks (LAMP, MEAN, MER)
- Early exposure to Convex at a 2021 office meetup did not sway original negative opinion
T3 Stack Origins & Approach to Backend Modularity 04:53
- Created the T3 stack to revive the spirit of flexible, modular web stacks he preferred
- Explained reasoning for modular tools: avoid lock-in, enable fast iteration, guarantee type safety, and maintain a single source of truth
- Early backend proposal focused on exposing backend logic directly in the frontend code with explicit type safety
- Settled on TRPC for end-to-end type safety after evaluating BlitzJS (too monolithic) and other options
Convex First Impressions and Reservations 17:52
- Became known as the TRPC advocate; Convex employee revealed TRPC inspired Convex's SDK
- Initially viewed Convex as a "monolithic closed-source startup," fostering concerns about lock-in and lack of portability
Revisiting Convex: Influences and Changing Perspectives 19:30
- Influential figures like Tanner Linsley and webdev Cody showed genuine interest in Convex, prompting reconsideration
- Realized Convex was more community-involved and open than initially thought
The Sponsorship Model and Conflict of Interest Concerns 21:47
- Details struggle with sponsor relationships, aiming for transparency but facing skepticism about influencer bias
- Switched sponsor model to clearly separate content from paid advertisements, thereby increasing channel profitability and clarity
Deep Dive into Convex: Features and Philosophy 32:04
- Convex structures backend logic in a centralized
convex folder containing schema, auth, and backend logic
- Recognized Convex as a true "infrastructure-as-code" platform—unlike others requiring manual dashboard or config file management
- Emphasized that everything is just code—mostly TypeScript—which benefits both developers and AI tooling for app generation
The “React for the Backend” Analogy 36:11
- Argues Convex provides backend primitives analogous to what React did for frontend: replaces complex, scattered state management with clear, code-centric updates
- Sync between code, database, and UI becomes immediate and intuitive, reducing mental overhead and sources of bugs
Real-World Experience and Technical Impact 45:53
- T3 Chat was rewritten to use Convex, moving away from a complex self-made local-first sync engine
- Highlights Convex’s advantage in consistency, ease of updates, and supporting server-driven application design
- Convex avoids pitfalls common to "local-first" databases and sync engines, focusing on code simplicity over heavy configurable complexity
Convex's Approach to Type Safety and Developer Experience 64:10
- Convex backend logic and schema are just TypeScript, which enjoys full stack type safety
- Codegen is lightweight—pointing to type definitions, not generating brittle code
- Any schema or backend change causes type errors directly in the frontend, aiding both human and AI development productivity
Live Demo and Underlying Mechanics 65:02
- Convex frontend uses hooks similar to React Query (
useQuery, useMutation) but with some unique quirks and annoyances (e.g., skipping via a magic string, direct returns)
- Backend queries are fully type-safe and validate input arguments
- Convex’s custom runtime (written in Rust, using V8) compiles all DB requests into atomic transactions, ensuring performance and consistency
Cache, Sync, and Real-Time Updates 80:10
- Query logic is compiled into cache keys, allowing real-time UI updates upon data changes—no need for manual cache invalidation or webhooks
- Changing data via the Convex dashboard or database instantly syncs to the UI without refreshes
Suitability and Limitations 59:16 / 61:08
- Ideal if all backend and frontend code is TypeScript and tightly coupled in a single application
- Not recommended if DB access/sharing is needed for external backends (e.g., Go, CLI), analytics, or other apps
- For analytics/data teams, suggests firehosing data elsewhere; Convex isn’t for multi-system DB sharing
Addressing Lock-In and Scaling Concerns 86:11
- Distinguishes between “provider-specific code” lock-in and “platform-provided primitives” lock-in—most Convex logic is the latter
- Convex now fully open source and can be self-hosted, making migration or reduction of provider reliance possible
- Scales well—builds atop proven infra (PlanetScale); handles major loads and offers transparent migration paths
Economics and Open Source Approach 94:00
- Convex is cost-effective, saving significant infrastructure expenses compared to prior stack (e.g., Versel, PlanetScale)
- Business model relies on startups and scale: ambitious teams can build faster and more efficiently on Convex, paying as they grow
Final Reflections & Recommendations 96:36
- Convex’s primitives dramatically improve developer experience, reliability, and speed—comparable to how React changed frontend development
- Argues Convex is not just for hobby apps—embraces scalability, openness, and flexibility
- For TypeScript-based applications needing end-to-end type safety and rapid iteration, Convex is a strong default
- Plans further deep-dives into Convex’s features and nuances in future content