Apollo-link-rest: Verschachtelte Rest-Cache-Umleitungen abfragen

Können Sie ein Minimalbeispiel erstellen, das das Problem demonstriert? AFAIK würde der Cache vor dem Restglied in der Kette liegen, also sollte er wie eine normale Abfrage gespeichert werden.

Ich werde versuchen, so schnell wie möglich ein Beispiel zu veröffentlichen. Caching funktioniert zwar, aber nur auf der obersten Ebene (z. B. für Bücher in meinem Beispiel), aber nicht bei verschachtelten, annotierten Objekten

@NikoSperat Wir haben eine PR- @export( verbessern möchte. Wenn Sie also einen Unit-Test beitragen könnten, könnten wir überprüfen, ob Ihr Anwendungsfall abgedeckt ist!

Siehe hier: https://github.com/apollographql/apollo-link-rest/pull/204

Ich glaube nicht, dass meine PR darauf eingehen wird, sie befasst sich nur mit der Korrektheit von @export Variablen. Anscheinend bezieht sich dieses Problem eher darauf, eine Cache-Überprüfung durchzuführen, bevor eine verschachtelte @rest Anfrage abgerufen wird.

Es scheint, als würde das Ziehen dieser Daten aus dem Cache einige Benutzereingriffe erfordern. Apollo wird nicht unbedingt wissen, dass der Benutzer bei /authors/{exportVariables.id} ein Author mit id=id . Als Entwickler sind Sie sich dessen bewusst, sodass Sie diese Informationen bereitstellen können, aber es scheint für die Bibliothek schwierig zu sein, Anwendungsfälle zu antizipieren, um Standardverhalten bereitzustellen.

Vielleicht würde eine benutzerdefinierte Abruffunktion, die in den Cache integriert ist, das erreichen, was Sie wollen.

Ich nehme an, ein id Parameter könnte der @rest Direktive hinzugefügt werden, die in Kombination mit type eine Cache-Überprüfung für Sie durchführen könnte. Aber ich würde mir auch Sorgen um solche versteckten Verhaltensweisen machen; Einige Benutzer (mich eingeschlossen) würden nicht erwarten, dass @rest standardmäßig zwischengespeichert wird und würden es vorziehen, dass ein verschachtelter Abruf die Ressource aktualisiert, selbst wenn sie zwischengespeichert ist. Nicht unbedingt ein schlechtes Feature, das hinzugefügt werden sollte, wenn es konfigurierbar ist und der Anwendungsfall klar definiert ist.

Es ist wie @a-type erklärt. Jetzt sehe ich hier die Probleme, warum es schwierig wäre, mit zwischengespeicherten Daten zu antworten.
Ich habe tatsächlich einen kurzen PoC mit einer benutzerdefinierten Abruffunktion und einer direkten Cache-Suche geschrieben. War nicht allzu schwierig, aber am Ende wird dies nur etwas mehr benutzerdefinierten Code hinzufügen, der schwer zu warten ist. - Das ist es, was wir versucht haben zu vermeiden und warum wir apollo und link-rest verwenden, anstatt unsere eigenen holenden Bibliotheken zu schreiben.
Es wäre wahrscheinlich eine gute Lösung, die Möglichkeit zu geben, eine benutzerdefinierte Umleitungsfunktion für verschachtelte Restobjekte bereitzustellen und diese zuvor aufzulösen

Ich denke, es gibt Potenzial, die Parameter id und cache @rest persönlich zu

Es würde der Bibliothek jedoch ein ziemlich bedeutendes Feature hinzufügen, daher würde ich es den Betreuern überlassen, zu entscheiden, ob es sich lohnt, es sich anzusehen.

Gibt es eine Möglichkeit, dies in der Zwischenzeit mit benutzerdefiniertem Code zu erreichen? Ich versuche genau das zu tun und würde mich über Hinweise sehr freuen

@typon Theoretisch könnten Sie readFragment möglicherweise innerhalb einer benutzerdefinierten fetch Funktion verwenden, indem Sie eine von Ihnen geschriebene Logik verwenden, um die Absicht der Anfrage durch die bereitgestellte URL zu bestimmen. Wenn readFragment Daten für die Ressource zurückgibt, können Sie sie so umpacken, dass sie wie eine normale Abrufantwort aussehen, und sie zurückgeben, anstatt die Anforderung zu stellen. Aber ich bin mir sicher, dass es beim Schreiben noch andere Fallstricke zu umgehen geben würde.

Ich habe diesem Thread nichts hinzuzufügen, wie in den Kommentaren von a-type gezeigt Weg. Es ist möglich, dass @typon @NikoSperat apollo-link-state (jetzt direkt ein Teil des apollo-Clients)

Sie sehen sich jedoch definitiv die Interna von Apollo an!

Wenn ich es wäre, würde ich dies in zwei Abfragen aufteilen, die die Arbeit nacheinander erledigen.

@fbartho ist dies für nicht verschachtelte @rest Abfragen dasselbe? Wird im Beispiel unten beispielsweise warehouses aus dem Cache aufgelöst, wenn eine Book Abfrage nach einer Books Abfrage aufgerufen wird? Ich war mir ziemlich sicher, dass es so sein wird, aber das ist es nicht. Verpasse ich etwas?

query Books
  books @rest(type: "[Book]", path: "/books") {
    id
    sku
  }
  warehouses @rest(type: "[Warehouse]", path: "/warehouses") {
    id
    name
  }
}

query Book
  book @rest(type: "Book", path: "/books/123") {
    id
    sku
  }
  warehouses @rest(type: "[Warehouse]", path: "/warehouses") {
    id
    name
  }
}

Eine detaillierte Kontrolle des Cachings ist eher eine Frage für ApolloClient. (Und einiges davon ist mit apollo-Links möglicherweise nicht einfach zu machen)

Außerdem bin ich mir ziemlich sicher, dass es mit reinem GraphQL auch diese beiden Arten von Abfragen nicht direkt aus dem Cache auflösen würde und auch dort zweimal Ihr Backend treffen würde.

GraphQL versteht nicht wirklich, dass die book-by-id-Abfrage genau äquivalent zu find-entry-in-books-list-query-that-matches-my-id ist. Macht das Sinn @edgars-sirokovs ?