4 ms·
Most applications don't even need to optimise for N+1 queries and the ones that do could get by with just optimising it in a few places. Measure first then opti
by DanielHB 3y ago
Most applications don't even need to optimise for N+1 queries and the ones that do could get by with just optimising it in a few places. Measure first then optimise as you see the need.
GraphQL batching together what would be multiple waterfall REST requests is such a perf boost for most cases that N+1 is really only an issue if your DB is bottlenecked.
- tango12 3y agoI think there are 2 subtleties here on where you optimize perf: 1. Frontend makes n+1 requests to the api. Either use GraphQL or build a custom endpoint that shapes a perfect response. 2. Build an api server that fetches data from the db efficiently without n+1 hitting the DB. The whole tension introduced with resolver/data-loader ways of building GraphQL, is that while it makes 1 easy, it makes 2 harder. Compared to bespoke REST-ish endpoints.
- DanielHB 3y agotrue, but ORMs also make 2. harder
- bastawhiz 3y agoI'd normally agree, but this is dangerous advice. Why? Because by the time you notice, it's not slow, it's down. N+1 queries don't scale badly as a function of users, it scales badly as a function of cumulative user behavior. One unexpectedly active user can make you self-DoS your database. Even a DB proxy like pgbouncer won't really help because parameterized queries are likely implemented with stored procedures, which require an exclusive DB connection, layering bottlenecks on bottlenecks.
- SkyPuncher 3y agoIn my experience, you typically don’t just improve past slwo with n+1s. Sure, if you introduce an n+1 to a large, existing table it will slow down. However, most endpoints are going to start at zero.