How We Made Shopify API Calls 10x Faster

Shopify's GraphQL API has a cost-based rate limit. Every query costs points, and you get a fixed budget that refills over time. Most apps either ignore this and hit throttle errors, or play it safe and crawl. We found a middle ground that makes Polaris significantly faster than either approach.

Cost-aware throttling

Every Shopify GraphQL response tells you how many points you have left. Polaris reads this after every request and adjusts its pace in real time. When the budget is healthy, requests fire as fast as possible. When it starts running low, Polaris automatically slows down just enough to avoid hitting the limit — while keeping a 100-point reserve so other app functions never get starved.

This is fundamentally different from static rate limiting. Instead of saying "only send 2 requests per second," Polaris says "send as many as the budget allows." The result is maximum throughput without a single throttle error.

Parallel fetching with 20 concurrent workers

When loading a store's translation data, Polaris doesn't fetch resources one after another. It runs up to 20 concurrent API calls, pulling products, collections, pages, and articles simultaneously. Combined with cost-aware throttling, this means we use the full API budget without wasting any of it on idle time.

Locale data follows the same pattern. When you open a resource, Polaris fetches translation status for every configured language in parallel instead of checking them sequentially. A store with ten languages loads almost as fast as one with two.

Retry with exponential backoff

Network requests fail. APIs return 500 errors. Connections drop. Rather than surfacing every transient failure to the user, Polaris retries failed requests automatically with exponential backoff. The first retry happens almost immediately; subsequent retries wait progressively longer. Most transient errors resolve themselves without the user ever noticing.

Progressive rendering

Large stores can have thousands of resources. Waiting for every product to load before showing anything creates a poor experience. Polaris uses progressive rendering: resources appear on screen as they're fetched, with the page filling in incrementally. You can start working immediately while the rest of your catalog loads in the background.

The combined effect

None of these optimizations is revolutionary on its own. But together — cost-aware throttling, parallel fetching, automatic retries, and progressive rendering — they add up to a dramatically faster experience. Pages that used to take 30 seconds to load now appear in under 3. Bulk operations that would time out now complete reliably. And merchants never see a rate limit error.