performance

ETag + last_modified for expensive Turbo Frame endpoints

Turbo Frames can trigger lots of small requests, so caching matters. For expensive frame endpoints (like an activity panel), I use stale? with an ETag that includes a cache key and the latest update timestamp. If the content hasn’t changed, Rails retu

Prisma: avoid N+1 with include/select

Prisma makes it easy to write readable queries, but you can still create N+1 patterns by fetching parents and then fetching children in a loop. I prefer using include or select to get related data in one query when the cardinality is reasonable. I als

Django caching with cache_page and cache decorator

I use Django's cache framework to avoid expensive queries and computations. The cache_page decorator caches entire view responses by URL. For more control, I use the low-level cache API to store query results or computed values. I set reasonable timeo

Django performance monitoring with django-silk

Django Silk profiles SQL queries, HTTP requests, and Python code. I install it in development to identify bottlenecks. It shows query counts, execution times, and duplicate queries per request. The web UI visualizes performance data. I use @silk_profi

Targeted Query Caching for Expensive Endpoints

I’ve had endpoints where the same lookups get repeated across helpers and partials, and I didn’t want to pay for query caching on every request. In Scoped query cache, I wrap only the expensive report build in ActiveRecord::Base.cache, so the cache li

Parallelize Independent External Calls (in a bounded way)

If you have to hit multiple APIs, you can cut tail latency by running calls concurrently. Keep it bounded and use timeouts. Rails itself is thread-safe for reads; be careful with DB connections and use with_connection for threaded work.

ETag + conditional GET for read-heavy endpoints

For read-heavy endpoints, clients often fetch the same resource repeatedly (profile data, settings, a snip page) even when it hasn’t changed. ETags let the client send If-None-Match and the server respond with 304 Not Modified, saving bandwidth and CP

Django select_related and prefetch_related for N+1 query optimization

The N+1 query problem is Django's most common performance trap. I use select_related for foreign key and one-to-one relationships (performs SQL JOIN), and prefetch_related for many-to-many and reverse foreign keys (separate queries with Python join).

Database Views for Read Models

Some read paths want a denormalized shape without materializing a new table. Postgres views are a clean option. Keep the view definition in a migration and map it with a read-only model.

Partial index for “active” rows in Postgres

Not all queries benefit from a full-table index, especially when most rows are ‘inactive’ or archived. A partial index lets you index only the subset you care about (like active users or un-deleted records), which shrinks index size and improves cache

Server-rendered skeleton UI for slow frames

For slow endpoints, I like a skeleton placeholder rather than a blank area. Turbo Frames make this easy: render a “loading skeleton” inside the frame tag as the initial content, then set src so Turbo fetches the real content. When the response arrives

Cache Stampede Protection with race_condition_ttl

If a hot key expires, you can stampede your DB. race_condition_ttl lets one process recompute while others serve stale content briefly. This is a reliability pattern masquerading as caching.