Implement cost-aware querying and cursor pagination against Jobber's GraphQL API to avoid throttling

Steps

1. Read the extensions.cost object returned on every response (requestedQueryCost, actualQueryCost, throttleStatus.maximumAvailable/currentlyAvailable/restoreRate) to understand your current budget
2. Always supply a first or last argument on connection fields — omitting it makes the API assume a maximum of 100 nodes when calculating requestedQueryCost, inflating cost dramatically
3. Use Relay-style cursor pagination (first/after with pageInfo.endCursor/hasNextPage) to fetch data in bounded pages instead of one large query
4. Avoid deeply nested connections (e.g. jobs → visits) when you don't need the nested data; query the narrower single-object field instead of the plural connection when possible
5. If a query is throttled (errors contain a THROTTLED code), back off and wait based on currentlyAvailable and restoreRate before retrying rather than immediately re-requesting
6. For bulk syncs, add a timed delay between calls so currentlyAvailable points can regenerate at restoreRate rather than bursting through the budget