Hallo zusammen,
ich arbeite mit dem Shopify GraphQL Step in Synesty und habe eine Frage zur korrekten Umsetzung der Pagination, wenn sich mehrere Ebenen von Connections ergeben.
Konkret:
-
Ich hole mir Bestellungen über orders(first: 100).
-
Innerhalb der Orders frage ich die lineItems(first: 10) ab.
-
Bei Orders mit mehr als 10 LineItems bekomme ich wie erwartet ein hasNextPage = true und einen endCursor.
Meine Herausforderung:
Wie setze ich die Pagination in Synesty sauber um, wenn ich sowohl auf der Orders-Ebene als auch auf der LineItems-Ebene paginieren muss?
Also:
-
Schleife über alle Orders (Pagination via after: endCursor).
-
Innerhalb jeder Order erneut Schleifen für die lineItems, bis alle geladen sind.
Gibt es ein Best-Practice-Beispiel, wie man so ein verschachteltes Pagination-Szenario im Flow aufbaut?
Vielen Dank!
Hallo @Henry-EG-Interfaces,
Nachtrag: Ich benutze den GraphQL-Schritt nicht, sondern mache das alles mit dem APICall. Hoffe einfach mal, dass sich der Ansatz auch in den GraphQL-Schritt transferieren lässt.
Hatte mich in den letzten Tagen auch mit den verschachtelten Abfragen beschäftigt, aber nur in der Theorie. Im Moment habe ich immer noch eine Verschachtelung vermieden, indem ich die untergeordnete Connection sehr großzügig abrufe. Also 250 Lineitems statt nur 10 im Falle der Bestellungen. Das geht aber natürlich sehr auf die Query-Kosten bzw. die Abrufgeschwindigkeit.
Diese Paginierung für die Bestellungen, Produkt oder was man auf der oberen Ebene hat, setzt ich bei mir per Variable mit
<#assign end_cursor = getVariable('end_cursor')>
und in meinen GraphQL-Variablen habe ich sowas wie:
"variables": {"numProducts": 100, "cursor": <#if end_cursor == "">null<#else>"${end_cursor}"</#if>}
end_cursor wird im Parsing-Template vor dem Aufruf von NextURL gefüllt, falls vorhanden. Soweit bist du aber vermutlich auch schon.
Für die Verschachtelung müsste man dann eine zweite Variable haben, in die man eine Liste aller Bestellung-IDs + LineItems-Cursor packt (Set/GetVariable kann mit Listen arbeiten).
Der RequestBody enthält im Endeffekt zwei komplette Queries (einmal für den Bestellabruf und einmal für die Verarbeitung des LineItem-Cursors in eine bestimmten Bestellung), zwischen denen man per IF/ELSE hin und her schaltet.
Wenn Elemente in der Liste mit Bestellung-IDs + LineItems-Cursor vorliegen, schaltet man auf die zweite Query um und verarbeitet ein Element aus der Liste. Anschließend löscht man den Eintrag aus der Liste oder aktualisiert ihn, wenn es weitere LineItems für die Bestellung gibt.
Hoffe, das macht nicht nur in meinem Kopf Sinn 
.
Gruß
Gustav
1 „Gefällt mir“
Guten Morgen @gustavfriedeheim,
vorab vielen Dank für die ausführliche Antwort!
Ich werde das Ganze einmal durchtesten - eventuell auch direkt über den API-Call. In der Regel kommen wir mit den 250 LineItems gut zurecht, allerdings hat mich hier interessiert, wie sich das ganze korrekt umsetzen lässt.
Soweit ich weiß, werden bei den Query Costs nur die tatsächlich zurückgegebenen Datensätze berechnet. Auch wenn wir 250 Line Items anfragen, aber nur 5 zurückbekommen, werden nur diese 5 für die für die actual query costs berücksichtigt.
Freundlicher Gruß,
Henry
Hallo @Henry-EG-Interfaces,
die Querykosten sind die tatsächlichen Kosten und nicht die theoretischen Kosten, das ist richtig.
Eine pauschale Rate festlegen für so einen Abruf ist aber mehr oder weniger unmöglich und kann immer scheitern. Wenn das angebundene Shopifysystem bei euch nun plötzlich haufenweise B2B-Bestellungen mit 250+ Positionen anlegt, ist das gewählte Ratelimit möglicherweise nicht langsam genug. Um auf der sicheren Seite zu sein, muss man sich beim Ratelimit immer am Worstcase orientieren.
In deinem Screenshot sieht man die API-Limits von einem Plus-Account, also 20000 statt 2000 als maximumAvailable und 1000 statt 200 als restoreRate. Damit ist die Problematik sicherlich weniger präsent, aber auch nicht ausgeschlossen.
Siehe auch mein Beispiel in Dynamische Abrufraten für APICall/GraphQL etc für mehr Details.
Gruß
Gustav
