Long-form writing on software engineering, systems design, and building things. (Page 3)
In this final part, we connect the dots. All frontend performance optimizations—caching, SSR, bundle splitting—are ultimately enabled or constrained by the backend. Learn how schema design, API ergonomics, and a full-stack mindset are the true foundation of a high-performance application.
A fast app that crashes is a failed app. This post tackles the unique challenges of GraphQL error handling, from partial data responses to network failures. Learn to build resilient UIs with skeleton loaders, intelligent retry policies, and centralized logging.
Your app is only as fast as its JavaScript payload. This guide tackles bundle bloat from heavy SDKs and GraphQL clients, teaching practical patterns like dynamic imports and selective client loading to drastically cut down your JS size without hurting developer experience.
Go beyond client-side rendering. This guide demystifies Next.js data fetching: getStaticProps, getServerSideProps, and Incremental Static Regeneration (ISR). Learn how to balance blazing-fast loads and SEO with the hidden costs of server load and hydration.
Efficient data fetching is only half the battle. This post explores the art of client-side caching, from the magic of normalized data in Apollo/Relay to bulletproof invalidation strategies and SSR hydration. Learn why great caching is as much about predictability as it is about performance.
Stop request waterfalls and N+1 problems at the source. This deep-dive covers advanced GraphQL data fetching patterns like fragments, query batching, cursor-based pagination, and real-time subscriptions to build truly performant clients.
Modern frontend performance bottlenecks often originate at the API layer. Instead of just identifying the problem, this post provides a blueprint for a solution, covering data fetching, caching, SSR, and more, kicking off a deep-dive series into building truly high-performance UIs.
Most teams reach for embeddings before they need them, wiring up pgvector when Postgres’s full-text search would have done the job. If your users are just looking for “caching” and expect to find “Rails caching strategies,” full-text search is fast, precise, and already built in. Where embeddings shine is when meaning matters more than exact words, like an e-commerce query for “summer outfit” that should return linen shirts and beach dresses. The key isn’t choosing one tool over the other, but knowing when Postgres alone is enough and when a hybrid approach gives you the semantic nuance users actually need.
Peak traffic was crushing our API—P95 latency at 450ms, dashboards taking 5 seconds to load, and users complaining of “slow mornings.” By introducing a Redis caching layer designed around real access patterns, not just generic key-value storage, we cut P95 latency in half, reduced DB CPU load from 85% to 45%, and eliminated the majority of timeouts. This is the story of how intentional caching turned a struggling system into one that scaled gracefully.
The moment I realized we had a problem was when our QA engineer asked, 'How do we know if someone accidentally changed how the AI behaves?' We had prompts scattered across a dozen files, each slightly different, with no way to test or version them. It hit me: we were making the same mistakes Rails solved 15 years ago with hardcoded strings. AI prompts aren't just text, they're critical business logic that shapes user experience. So I built Promptly to bring Rails conventions to AI development, treating prompts like the first-class citizens they should be. The result? 60% faster AI feature development and actual regression testing for AI behavior. Sometimes the best solutions aren't about new technology; they're about applying proven patterns to new problems.