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.
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.
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.
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:
Spørringskompleksitet er proporsjonal med dataene du forespørrer. Strukturer spørringene dine til å hente bare feltene og objektene du faktisk skal bruke.
1query{
2 order(orderId:"order_123"){
3 id
4 status
5 createdAt
6 updatedAt
7 items {
8 id
9 name
10 quantity
11 amount
12}
13 shipments {
14 id
15}
16}
17}
Paginer store datasett
Når du forespør flere objekter, bruker du rimelige sidestørrelser:
1{
2 orders(first:100, filter:{status: COMPLETED }){
3 edges {
4 cursor
5 node {
6 id
7}
8}
9}
10}
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
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.
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:
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
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") {idcreatedByshipToCountry}}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 {cursornode {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") {idcreatedAt}order(orderId: "order_123") {idstatuscreatedAt}}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") {idstatuscreatedAtupdatedAtitems {idnamequantityamount}shipments {id}}}Paginer store datasett
Når du forespør flere objekter, bruker du rimelige sidestørrelser:
{orders(first: 100, filter: { status: COMPLETED }) {edges {cursornode {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.
Var denne siden nyttig?