Dieses Kapitel füllt etc/schema.graphqls des Event-Moduls erstmals mit echtem Inhalt: dem Event-Typ und einer Liste-Query, die dieselbe Pagination-Struktur nutzt wie Magentos eigene products-Query.

Warum nicht einfach eine Liste zurückgeben?

Eine Query, die direkt [Event] zurückgibt, wäre die naheliegendste Lösung - und genau die falsche für alles, was potenziell viele Datensätze umfasst. Ohne Paginierungsinformationen kann ein Client weder wissen, wie viele Veranstaltungen insgesamt existieren, noch gezielt "die nächsten 20" nachladen. Magento löst das im gesamten Core konsistent über das Connection-Pattern: ein Wrapper-Typ mit items, page_info und total_count.

Den Event-Typ deklarieren

type Event @doc(description: "A single event") {
    event_id: Int!
    identifier: String!
    title: String!
    description: String
    location: String!
    start_at: String!
    end_at: String
    capacity: Int
}

Die Non-Null-Markierungen folgen der Faustregel aus Kapitel 7: Spalten mit nullable="false" in db_schema.xml (Kapitel 11) werden als ! deklariert, optionale Spalten wie capacity bleiben nullable. Datum/Uhrzeit-Felder sind bewusst String, nicht ein eigener Skalar (Kapitel 6).

Der Wrapper-Typ für die Liste: Events

type Events @doc(description: "A paginated list of events") {
    items: [Event]
    page_info: SearchResultPageInfo
    total_count: Int
}

SearchResultPageInfo ist kein eigener Typ, sondern ein bereits vorhandener Core-Typ aus Magento_CatalogGraphQl (page_size, current_page, total_pages) - dieselbe Wiederverwendung wie FilterTypeInput in Kapitel 3 und 6. Er kann direkt referenziert werden, solange die in Kapitel 4 gesetzte Modulabhängigkeit auf Magento_CatalogGraphQl besteht.

Die Query mit Pagination-Argumenten

type Query {
    events(
        pageSize: Int = 20
        currentPage: Int = 1
    ): Events
        @resolver(class: "Mironsoft\\Event\\Model\\Resolver\\Events")
        @doc(description: "Returns a paginated list of active events")
}

pageSize und currentPage sind bewusst optional mit sinnvollen Defaults (Kapitel 7) statt zwingender Pflichtargumente - ein Client, der einfach nur "die ersten Veranstaltungen" sehen will, braucht keine Paginierungsargumente mitzugeben.

query {
  events(pageSize: 5) {
    items {
      identifier
      title
      start_at
    }
    page_info {
      current_page
      page_size
      total_pages
    }
    total_count
  }
}

Kapitel 13 macht diese Query lebendig: DataProvider und Resolver, die echte Veranstaltungsdaten aus der Datenbank liefern.