GraphQL-lekérdezés-építő

Az Adobe Commerce headless kirakatai GraphQL-en kérdezik le a katalógust. Rakd össze a lekérdezést vizuálisan (vagy írd kézzel): a szerver egy saját, PHP-ban írt értelmezővel dolgozza fel, fix séma ellen validálja, mélység- és komplexitás-korlátot alkalmaz, majd batch-elt resolverekkel hajtja végre. A válasz mellett a végrehajtási tervet és az időmérést is látod.

Lekérdezés

Alap lista
N+1 és batch-elés
Szűrés + aggregációk
Túl mély
Túl komplex
Szintaktikai hiba
Kategória (category_uid)

Szín

piros
kék
fekete
fehér
zöld

Méret

S
M
L
XL

Márka

Aurora
Borealis
Corona
Rendezés
pageSize

Lekért mezők

A generált GraphQL-lekérdezés
{
  products(pageSize: 5) {
    total_count
    page_info { current_page page_size total_pages }
    items {
      sku
      name
      price_range {
        minimum_price {
          regular_price { value currency }
          final_price { value currency }
        }
      }
      categories { name url_key }
    }
  }
}

A fix séma (részlet)

type Query {
  products(search: String, filter: ProductAttributeFilterInput,
           pageSize: Int = 20, currentPage: Int = 1,
           sort: ProductAttributeSortInput): Products
}
type Products {
  items: [ProductInterface]  total_count: Int
  page_info: SearchResultPageInfo  aggregations: [Aggregation]
}
type ProductInterface {
  uid: ID  sku: String  name: String  stock_status: ProductStockStatus
  color: String  size: String  brand: String  price_range: PriceRange
  categories: [CategoryTree]  related_products: [ProductInterface]
}
type CategoryTree { uid: ID  name: String  url_key: String  product_count: Int }
input ProductAttributeFilterInput {
  category_uid: FilterEqualTypeInput  color: FilterEqualTypeInput
  size: FilterEqualTypeInput  brand: FilterEqualTypeInput
  price: FilterRangeTypeInput
}
input ProductAttributeSortInput { relevance: SortEnum  name: SortEnum  price: SortEnum }

Mit csinál a szerver egy GraphQL-kéréssel?

A kérés egy szöveg, amit a szerver nem futtat, hanem értelmez: a lexer tokenekre bontja, a parser szintaxisfát épít belőle, a validátor pedig a fix séma ellen ellenőrzi (létező mezők, helyes argumentum-típusok, a levél- és összetett mezők szabályai). Nincs eval, nincs dinamikus osztály- vagy metódusnév: csak a sémában rögzített mezők oldódnak fel, fix resolverekkel.

Egy nyilvános GraphQL-végpont legnagyobb kockázata a drága lekérdezés: néhány sor szöveg, ami egymásba ágyazott listákkal több ezer objektumot kérne le. Ezért a végrehajtás ELŐTT két korlát fut: a mélység (itt legfeljebb 6 szint) és a komplexitás, ahol minden mező a felette lévő listák várható méretével szorzódik. Az Adobe Commerce is alkalmaz mélység- és komplexitás-korlátot a GraphQL-kérésekre.

Az N+1 probléma: ha a kategóriákat vagy a kapcsolódó termékeket termékenként külön kérdeznénk le, egy 20 elemes lapnál 20 extra lekérdezés futna mezőnként. A végrehajtó ezért szintenként halad, és egy mező resolverét a szint összes szülőjére egyszerre hívja (DataLoader-minta); a Magento ugyanezt a batch-resolverekkel oldja meg.

A demó egy jól körülhatárolt részhalmazt valósít meg: egyetlen query-művelet, mezők, aliasok és literál-argumentumok. Kimaradnak a változók, a fragmentek, a direktívák, a mutation és az introspekció. Ezek a nyelv teljességéhez kellenek, de a parser felületét és a támadási felületet növelnék anélkül, hogy a lényeget (validálás, korlátok, batch-elt végrehajtás) gazdagítanák.