Analys av frågekomplexitet

När ni bygger GraphQL-API:er kan klienter begära stora mängder data i en enda fråga. Denna flexibilitet är kraftfull, men innebär också en risk.

Frågekomplexitet syftar på hur mycket "arbete" servern måste utföra för att uppfylla en viss GraphQL-fråga. Det handlar inte bara om datamängden, utan även om de resurser som krävs.

Utan begränsningar kan en skadlig eller dåligt skriven fråga begära en orimligt stor mängd djupt nästlade data eller mycket stora listor.

• Det kan tömma serverresurser (CPU, minne, databasanslutningar).
• Det kan leda till långsamma svarstider för alla användare.
• I extrema fall kan det orsaka en Denial-of-Service-attack (DoS), vilket gör ert API otillgängligt.

Genom att analysera frågans komplexitet kan ni förhindra dessa problem.

Föreställ er en fråga som hämtar användare, deras inlägg, kommentarer till dessa inlägg och författarna till kommentarerna. Det skapar en djup, nästlad struktur:

users {
  posts {
    comments {
      author {
        name
      }
    }
  }
}

Varje nästlingsnivå kan innebära fler databasfrågor eller tjänsteanrop, vilket snabbt mångfaldigar serverns arbetsbörda.

För att hantera komplexiteten använder vi ofta en "kostnadsbaserad" metod. Det innebär att varje del av en GraphQL-fråga tilldelas en numerisk kostnad.

• Skalärer: Enkla fält som name eller id kan ha en låg kostnad (t.ex. 1).
• Objekt: Komplexa typer som User eller Post kan ha en grundkostnad plus summan av deras valda fält.
• Listor: Ett fält som returnerar en lista (t.ex. posts) är mer komplext. Kostnaden kan vara base + (number_of_items * item_cost).

Den totala kostnaden för en fråga är summan av kostnaderna för alla dess fält.

Föreställ er en förenklad "fråga" som en trädstruktur. "Kostnaden" kan vara det totala antalet noder. Den här Java-koden visar hur det totala antalet noder i en sådan struktur beräknas.

Prova att köra exemplet:

I en Spring Boot GraphQL-applikation tillhandahåller det underliggande biblioteket graphql-java verktyg för komplexitetsanalys. Den centrala komponenten är en Instrumentation.

En Instrumentation är en krok som gör det möjligt att observera och ändra körningen av en GraphQL-fråga. För komplexitetsanalys använder vi implementationer som MaxQueryComplexityInstrumentation.

Ni konfigurerar MaxQueryComplexityInstrumentation med ett högsta tillåtet komplexitetsvärde. Om kostnaden som beräknats för en inkommande fråga överskrider denna gräns stoppas körningen.

Detta hindrar servern från att behandla alltför kostsamma frågor och skyddar era resurser. Klienten får ett felmeddelande i stället för ett fullständigt datasvar.

När en fråga överskrider den konfigurerade maximala komplexiteten returnerar GraphQL-servern vanligtvis ett specifikt felmeddelande. Meddelandet informerar klienten om att frågan var för komplex.

Exempel på fel (förenklat):

{
  "errors": [
    {
      "message": "Query complexity of 1500 exceeds max allowed 1000"
    }
  ]
}

Detta gör det möjligt för klienter att anpassa sina frågor.

Utöver enkel räkning av noder kan ni definiera mer detaljerade kostnadsregler:

• Fältspecifika kostnader: Tilldela högre kostnader till fält som är kända för att vara dyra (t.ex. bildbehandling och anrop till externa API:er).
• Argumentbaserade kostnader: Justera kostnaden utifrån argument. Ett fält som products(limit: Int) kan till exempel kosta 1 + (limit * 5).
• Djupbegränsning: En enklare form av komplexitetsanalys som bara begränsar hur djupt nästlad en fråga får vara, utan att beräkna en fullständig kostnad.

I den här lektionen har vi lärt oss om analys av frågekomplexitet. Det är en viktig teknik för att mäta "kostnaden" för en GraphQL-fråga och sätta gränser som förhindrar överbelastning av servern och DoS-attacker.

• Vi har förstått hur djup nästling och stora listor bidrar till komplexiteten.
• Vi har gått igenom den kostnadsbaserade metoden, där fält tilldelas numeriska kostnader.
• Vi har diskuterat hur graphql-java och Spring Boot använder Instrumentation för att upprätthålla dessa gränser.

Härnäst utforskar vi cachelagringsstrategier för att ytterligare förbättra ert API:s prestanda!