Hvorfor kompleksitetsbasert hastighetsbegrensning?
Tradisjonelle REST-APIer bruker forespørselsbasert hastighetsbegrensning der hver forespørsel forbruker de samme kredittene, enten du henter ett felt eller hundrevis, og enten du leser eller endrer data – til tross for den betydelige forskjellen i serverbelastningen.
GraphQL sin tilnærming basert på spørringskompleksitet løser dette ved å beregne kostnader basert på de faktiske dataene som forespørres og operasjonene som utføres. Dette gir deg mer fleksibilitet til å forespørre det du trenger, samtidig som du får forutsigbar serverbelastning.
Hastighetsbegrensning
Zonos bruker et poengbasert system der hver spørring trekker fra poeng basert på kompleksiteten. Du har et poengbeholdning som:
- Fylles på med 3 000 poeng per sekund (30 000 poeng per 10 sekunder)
- Har en maksimal kapasitet på 300 000 poeng
Dette lar deg gjøre økt aktivitet med komplekse spørringer fra tid til annen, samtidig som du opprettholder et bærekraftig forespørselstempo.
Hvordan spørringskostnaden beregnes
Hver GraphQL-forespørsel har en kostnad som beregnes før utføring:
Grunnleggende kostnader
- Spørring: 5 poeng
- Mutasjon: 10 poeng
- Objekt: 1 poeng per objekt som returneres
- Skalarfelter: 0 poeng (gratis)
Skalarfelter som strenger, heltall, ID-er og boolske verdier legger ikke til kostnaden. Du betaler bare for basistransaksjonen og objektene som returneres.
Eksempel: Enkel spørring
query { landedCost(id: "123") { id createdBy shipToCountry }}Kostnadsfordeling: 5 (grunnleggende spørring) + 1 (landed cost-objekt) = 6 poeng
Skalarfeltene (id, name, currency) er gratis.
Eksempel: Spørring med flere objekter
{ orders(first: 10, filter: { status: COMPLETED }) { edges { cursor node { id } } }}Kostnadsfordeling: 5 (grunnleggende spørring) + 10 (10 ordrer × 1 poeng hver) = 15 poeng
Eksempel: Mutasjon
mutation { landedCostCalculate(input: { ... }) { id }}Kostnadsfordeling: 10 (grunnleggende mutasjon) + omtrent 50 (objekter som returneres) = 60 poeng
En typisk landed cost-beregning koster omtrent 60 poeng i kompleksitet.
Visning av spørringskompleksitet
Hvert API-svar inkluderer en zonos-query-complexity-header som viser kostnaden for spørringen din:
zonos-query-complexity: 58Denne headeren forteller deg nøyaktig hvor mange poeng spørringen forbrukte. Bruk den til å overvåke API-bruken din og optimalisere dyre spørringer.
Håndtering av hastighetsbegrensninger
Hvis du overskrider hastighetsbegrensningen, mottar du en feilmelding. For å håndtere hastighetsbegrensninger effektivt:
Overvåk kompleksiteten din
Sjekk zonos-query-complexity-headeren i svar for å forstå spørringskostnadene dine og identifisere dyre mønstre.
Implementer gjenprøvingslogikk
Hvis du treffer hastighetsbegrensninger, implementer eksponentiell backoff og gjenprøvingslogikk. Siden beholdningen fylles på med 3 000 poeng per sekund, beregner du passende ventetider basert på spørringskompleksiteten din.
Batch effektivt
GraphQL lar deg forespørre flere spørringer i en enkelt forespørsel:
{ landedCost(id: "landed_cost_123") { id createdAt } order(orderId: "order_123") { id status createdAt }}Beste praksis
Forespørr bare det du trenger
Spørringskompleksitet er proporsjonal med dataene du forespørrer. Strukturer spørringene dine til å hente bare feltene og objektene du faktisk skal bruke.
query { order(orderId: "order_123") { id status createdAt updatedAt items { id name quantity amount } shipments { id } }}Paginer store datasett
Når du forespør flere objekter, bruker du rimelige sidestørrelser:
{ orders(first: 100, filter: { status: COMPLETED }) { edges { cursor node { id } } }}Forespørr 10–50 elementer av gangen og paginer gjennom resultatene etter behov, i stedet for å forespørre hundrevis av objekter i en enkelt spørring.
Unngå unødvendig nesting
Hvert nestet objekt legger til kompleksiteten din. Forespørr bare nestede data når du faktisk trenger det.
GraphQL API-hastighetsbegrensning
Lær hvordan Zonos beregner spørringskostnader basert på kompleksitet.
Zonos setter grenser for GraphQL API-forespørsler basert på spørringskompleksitet i stedet for antall forespørsler. Dette sikrer rettferdig bruk samtidig som det lar deg forespørre nøyaktig de dataene du trenger.