Apollo-link: [apollo-link-offline] Was ist deine Idee?

Was würden Sie als typischen Anwendungsfall bezeichnen?

Als Offline-App:

• Alle graphql-Anfragen werden der Warteschlange hinzugefügt. (kann im Cache gespeichert werden).
• Wenn die Anwendung das Online-Signal empfängt, informiert sie den Link, um die vorherige Anfrage erneut zu senden.

Ich stelle mir vor, dass es so verwendet wird:

import { NetInfo } from 'react-native';
import OfflineLink from 'apollo-link-offline';

const offlineLink = new OfflineLink({
  isOnlineAsync: () => NetInfo.isConnected.fetch(),
});

NetInfo.isConnected.addEventListener('change', (isConnected) => {
  if (isConnected) {
    offlineLink.resubmit();
  }
});

Ich denke, das wäre ein erstaunliches Stück Funktionalität. Meines Erachtens könnte es passieren, dass Apollo-link-offline eine Reihe von Abfragen und Mutationen definiert, die offline verwendet werden müssen.

Sobald diese definiert sind, können wir im Hintergrund der Anwendung alle Daten aus den Abfragen abrufen und im lokalen Speicher speichern. Für die Mutationen benötigen wir alle Felder, die im lokalen Speicher erstellt wurden, damit wir alle offline erstellten Daten speichern können.

Auf diese Weise können wir auch offline Funktionen ausführen, während die Daten in einem lokalen Cache gespeichert werden.
Wir würden auch die PWA-Tests von Google bestehen, wenn wir auf Service Workers verlinken könnten
Wenn die App dann wieder online ist, können alle Mutationen, die im lokalen Cache aufgetreten sind, an die API zurückgegeben werden.

Offensichtlich müsste es eine Art Parallelitätsschutz geben.

Meine Sorge ist, dass Benutzer A (offline) Tabelle X aktualisiert, während Benutzer B (online) Tabelle X aktualisiert hat, während Benutzer A offline war. Wir bräuchten hier eine Form von Parallelitätsregeln. Ich denke, es könnte datumsgesteuert sein, aber es löst das Problem nicht, wenn Benutzer A die Daten von Benutzer B überschreibt, ohne dass Benutzer B dies bemerkt.

Oder wir könnten die Mutation einfach fehlschlagen und den Benutzer manuell aktualisieren lassen, wenn er wieder online ist.

Apollo Client 2 ist erstaunlich, aber diese Funktionalität wäre der absolute Hundescheiße

Ich wäre auch ein großer Fan davon. Ich weiß, dass es verschiedene Versuche gab, dies mit dem Redux Store von 1.0 anzugehen, aber es wäre ziemlich wunderbar, ihn zu einem vollwertigen Bürger des Apollo 2.0-Ökosystems mit einem konsistenten Ansatz zu machen.

Das meiste von dem, was hier behandelt wurde, macht für mich bereits viel Sinn – im Grunde möchte ich meine Daten auf einem lokalen Speicher speichern und sie dann von dort aus in Apollo ziehen. In zweiter Linie Mutationen in die Warteschlange stellen.

Als eine Art tertiäres Ziel wäre es auch großartig, noch mehr Daten im Hintergrund einsaugen zu können, und ich werde es trotzdem versuchen. Ich möchte eigentlich auch fast alle Daten des Benutzers lokal speichern, nur um allgemeine Abfragevorgänge viel schneller zu machen, und dann für volle Genauigkeit rehydrieren, wenn das Netzwerk es zulässt. Eine Art Lösung für diesen eifrig-für-später-Ansatz wäre also großartig, zumal Service-Mitarbeiter allmählich rentabel werden, da Safari sie endlich in der Tech-Vorschau hat.

Auch ich bin davon begeistert. @danieljvdm Hatte bei einem Problem im apollo-client-repo einen kleinen Vorsprung in Sachen Persistenz.

Ich denke, der RetryLink wird nützlich sein, um Netzwerkfehler und Falloff wie bei redux-offline sehen würde .

Das ist ziemlich cool. Das Problem, auf das @2WheelCoder verweist, ist ein früher und vielleicht naiver Ansatz, der eher auf die Beibehaltung des Caches als auf die vollständige Offline-Unterstützung ausgerichtet ist (Warteschlangen für Abfragen/Mutationen und dergleichen).

Es könnte immer noch ein anständiger Ort sein, um anzufangen und darauf aufzubauen. Was ich in diesem Problem darauf hingewiesen habe, ist, dass ich derzeit keine gute Möglichkeit habe, den Cache auf Änderungen zu überwachen. Ich habe heute tatsächlich versucht, den ursprünglichen Vorschlag von @2WheelCoder zu implementieren, gestoßen . Das Problem beim Erstellen eines ApolloLink zum "Überwachen von Speicheränderungen" besteht darin, dass er nur im Kontext zwischen einer Client-Aktion und dem anschließenden Cache-Schreiben lebt. So kann ich die Anfrage abfangen, bevor sie erlischt (Middleware) und sie abfangen, bevor sie in den Cache geschrieben wird (Afterware), aber ich weiß nicht, wann sie geschrieben wurde - ich kann nur raten (mein aktueller Hack ist ein 1000-ms-Timeout ).

Ein weiterer schwerwiegender Fehler bei der Verwendung eines Links für die Offline-Persistenz besteht darin, dass Abonnements nicht berücksichtigt werden. Ein Abonnement-Link wird nur ausgelöst, wenn das Abonnement geöffnet wird, nicht bei nachfolgenden Ereignissen (vielleicht gibt es eine Möglichkeit, die ich übersehen habe?).

Dies ist im Grunde, wo ich gerade bin, und ich stecke ziemlich fest - ich denke, um weiter zu kommen, muss ich möglicherweise eine PR für apollo-cache-inmemory öffnen.

@danieljvdm Ich bin an der gleichen Stelle und denke, dass es sinnvoll ist, die Persistenz direkt im Cache zu behandeln, nachdem Sie gerade auf dasselbe Problem gestoßen sind. Der HttpLink ist dafür einfach nicht geeignet, da das Observable nach der Anfrage, aber (normalerweise) vor den Cache-Updates abgeschlossen wird.

Obwohl es sich lohnen mag, eine PR zu apollo-cache-inmemory zu eröffnen, frage ich mich auch, ob es besser wäre, es in ein neues Projekt zu stecken. Die Modularität von Apollo 2 rund um Cache und Link scheint darauf hinzudeuten, dass Sie, wenn Sie eine andere Art von Cache benötigen, einfach bauen können. Vielleicht ist ein Problem mit apollo-client der nächste Schritt (ich glaube nicht, dass apollo-cache-inmemory ein eigenes Repo hat)?

Entschuldigung, dass die Links hier ein wenig vom Thema abgekommen sind.

@holman hätten Sie eine Referenz zum Servicemitarbeiter in der Safari-Tech-Vorschau?

@sedubois es ist vor ein oder zwei Monaten (irgendwie plötzlich) gefallen. Es ist in der technischen Vorschau , aber es gibt noch einiges zu tun .

@2WheelCoder Ich mag die Idee eines PR-to-Apollo-Clients für einen neuen Cache. Vielleicht apollo-offline-cache das apollo-cache-inmemory ? Daran würde ich gerne mitarbeiten. Möchten Sie dort ein Problem eröffnen?

@2WheelCoder @danieljvdm wie wäre es mit LocalForage für die Persistenz https://github.com/localForage/localForage

@danieljvdm Ja, ich werde ein Problem eröffnen, wenn Sie eine PR in

@Eishpirate Stimme definitiv zu, dass LocalForage großartig ist. Ich denke, die Art und Weise, wie Redux-Persist es geschafft hat, den Laden zu retten, war ziemlich solide und kann wahrscheinlich als anständiges Muster in apollo-offline-cache fungieren.

Leute, ich verwende das Redux Persist Package, um Speicherdaten in React native AsyncStorage zu speichern. Wie mache ich das jetzt? Irgendeine Idee?

@Eishpirate : Funktioniert localforage für React native? Wenn ich mir die Kompatibilitätstabelle der Bibliothek anschaue, kann ich nichts über React Native finden. https://github.com/localForage/localForage/wiki/Supported-Browsers-Platforms

Es wäre sehr schade, wenn die Offline-Funktion von apollo für Apps nicht funktionieren würde.

@timLoewel das ist ein sehr guter Punkt. Hatte nicht wirklich so weit gedacht wie React Native. Glaube nicht, dass es explizit so ist.

Dies kann später zu unerwarteten Problemen führen. Ich bin mir jedoch nicht sicher, ob es eine praktikable Alternative gibt, ohne das Rad neu erfinden zu müssen

Interessanter Artikel, der für diese Diskussion relevant sein könnte https://blog.logrocket.com/building-an-offline-first-app-with-react-and-rxdb-e97a1fa64356?t=now

Es sieht wirklich vielversprechend aus, wenn rxdb als Offline-Datenbank verwendet wird. Dies ist kompatibel mit React, React-Native, Vue, Angular, so ziemlich den beliebtesten Optionen.

Das Problem, das ich finde, ist jedoch, dass es mit einer NoSQL-Datenbank wie PouchDB (Derivat von CouchDB) synchronisiert werden muss. In meinem Anwendungsfall verwende ich eine relationale SQL-Datenbank (Postgres) und meine gesamte Datenvalidierung erfolgt auf Datenbankebene. Wenn ich dieses System verwenden müsste, müsste ich die Validierung über das jsonschema aufrechterhalten.

Es folgt nicht den DRY-Prinzipien und würde definitiv zu Problemen führen.

Eine andere Option, die ich gefunden habe, ist Kinto http://docs.kinto-storage.org/en/stable/index.html, das mit Postgres funktioniert und einige der zusätzlichen Komplexitätsebenen vermeiden sollte, die rxdb einführen würde. Kinto verwendet HTTP, also könnten wir es theoretisch einfach in Apollo-link-http https://github.com/apollographql/apollo-link/tree/master/packages/apollo-link-http stecken

Klingt, als würde ein Großteil der Arbeit mit dem Caching zusammenhängen.

Wie wäre es mit Redux? (Ich meine es ernst)

Ein apollo-link-offline- Paket, basierend auf der apollo-offline- Arbeit und...
Ein apollo-cache-redux- Paket. Verwenden Sie redux-offline/redux-persist genauso wie jetzt apollo-offline.

Apollo hat den Inmemory-Cache als allgemeine Standardlösung erstellt - ich kann verstehen, warum sie nicht so eng mit einer anderen Bibliothek verbunden sein wollten. Aber die Redux/Redux-Offline/Redux-Persis-Lösung ist so kampferprobt... sie ist immer noch eine gute Wahl. Die Entwicklung ist für alle drei sehr aktiv.

BEARBEITEN: apollo-cache-redux existiert jetzt dank @rportugal

@giatm Ich habe vor apollo-link-queue . Wenn jemand von euch Verbesserungsvorschläge hat, freue ich mich über Anregungen oder Beiträge.

Bitte wie ist der Stand dieses Problems? Gibt es etwas, das wir für Offline-Sachen verwenden können, das von Apollo stammt und nichts mit Redux Offline zu tun hat?

@schmiedaitufe ,
Ja, Sie können apollo-cache-persist verwenden .

@Gregor1971
Danke für diesen Hinweis. Ich werde es ausprobieren und meine Beobachtungen abgeben.
Auf der Oberfläche sieht es cool und einfach zu implementieren aus.

Wie unterscheidet sich das von apollo-link-queue

Hey Leute, ich habe versucht, eine grundlegende Implementierung für React-Native zusammenzustellen, die ein ähnliches Verhalten wie apollo-offline hat .
(pinging https://github.com/Malpaux/apollo-offline/issues/14)

Sie können es in dieser Zusammenfassung überprüfen: https://gist.github.com/lachenmayer/2e364a5ca9ae0918eb032867d0c6720d

Es ist eine Kombination aus:

• apollo-link-Warteschlange ,
• apollo-link-retry ,
• und eine benutzerdefinierte optimisticFetchLink Funktion.

Wenn das Gerät offline geht, werden Anforderungen in die Warteschlange gestellt und aus der Warteschlange entfernt, wenn es wieder online geht. ( apollo-link-queue )

Jede Anfrage, die mit einem Netzwerkfehler fehlschlägt, wird (derzeit unendlich) wiederholt. ( apollo-link-retry )
Beachten Sie, dass dies entweder daran liegen kann, dass das Gerät offline ist oder das Backend einfach nicht erreichbar ist (z. B. wenn es ausgefallen ist).

Wenn wir die Abfrage jedoch aus dem Cache auflösen können, wird sie nicht erneut versucht, sondern die Daten im Cache werden als Antwort verwendet. Dies ist in der Funktion optimisticFetchLink implementiert.

Meiner Meinung nach ist dieses "optimistische Abrufverhalten" einer der wichtigsten Bestandteile von apollo-offline, und jede zukünftige Implementierung von apollo-link-offline sollte dies unterstützen. Dies ermöglicht es dem Benutzer, die App im Offline-Modus wie gewohnt zu verwenden, solange die Daten abgerufen und zu einem bestimmten Zeitpunkt gespeichert wurden. Meiner Meinung nach sollte dies das Standardverhalten der network-and-cache Abrufrichtlinie sein , aber leider sieht es nicht so aus, als würde sich dies in absehbarer Zeit ändern (siehe https://github.com/apollographql/react-apollo/issues/ 604#issuecomment-355648596).

Wenn Sie das Wesentliche als offlineLink.js speichern, können Sie es wie folgt verwenden:

import { InMemoryCache } from 'apollo-cache-inmemory'
import { ApolloClient } from 'apollo-client'
import { createHttpLink } from 'apollo-link-http'

// get this from https://gist.github.com/lachenmayer/2e364a5ca9ae0918eb032867d0c6720d
import { createOfflineLink } from './offlineLink'

const cache = new InMemoryCache()
const networkLink = createHttpLink()

const offlineLink = createOfflineLink({ cache })

const link = ApolloLink.from([
  // ... + other links ...
  offlineLink,
  networkLink,
])

const client = new ApolloClient({
  cache,
  link,
}

Bekannte Probleme / fehlende Bits

• Dies funktioniert vorerst nur mit Reactive-Native. Der isOnline Check sollte abstrahiert werden, um dies plattformübergreifend zu machen.
• Wenn Sie nur eine teilweise Antwort im Cache haben, erhalten Sie irgendwann eine abgelehnte Zusage, die Ihnen mitteilt, dass die Antwort unvollständig ist. Ich habe noch nicht untersucht, wie man das beheben kann oder wie apollo-offline das löst. Wenn Sie versuchen möchten, dies zu beheben, würde ich mich über Hinweise dazu freuen.
• Sie können derzeit keine der Wiederholungseinstellungen ändern - dies sollte als zusätzlicher Konfigurationsparameter hinzugefügt werden.
• Sie haben keine Kontrolle über das optimistische Abrufen. Sie sollten dies für jede Abfrage unabhängig einstellen können. Ich bin kein großer Fan der Implementierung von apollo-offline (das Setzen einer {__online_: true} Abfragevariable), aber es sollte definitiv eine Möglichkeit geben, dies zu tun.
• Es gibt natürlich auch keine Tests.

Ich würde mich freuen, wenn jeder, der nach einer Lösung dafür sucht, dies ausprobieren kann, und wir können dies dann möglicherweise in ein richtiges npm-Modul mit Eingaben, Tests, Dokumenten und allem anderen umwandeln. Dieses Verhalten ist meiner Meinung nach super wichtig und es ist wirklich schade, dass apollo-client 2 dafür noch keine passende Lösung hat.

Schön ️

@schmiedaitufe ,

Wie unterscheidet sich das von apollo-link-queue?

Es sieht so aus, als ob apollo-link-queue basierend auf dem Verbindungsstatus intelligente Dinge tut. apollo-cache-persist speichert den Cache; So können Benutzer beispielsweise Ihre App starten und ausführen, während die Verbindung getrennt ist. Ohne den Cache beizubehalten, würde Ihre App zum Starten eine Konnektivität benötigen.

Wir werden wahrscheinlich beides oder noch besser die obige Lösung von

@lachenmayer Auf den ersten Blick sieht dein Ansatz sehr ansprechend aus.

Ich stimme Ihnen absolut zu, dass so etwas wie die optimistische Abruffunktion von apollo-offline notwendig ist. Es (oder eher das Fehlen davon) hat mich hauptsächlich dazu inspiriert, apollo-offline zu starten.

Ich selbst bin nicht ganz zufrieden damit, wie ich das selektive Aktivieren/Deaktivieren der optimistischen Abruffunktion in apollo-offline implementieren musste. Abfragevariablen waren nicht die erste Wahl, aber sie schienen die praktischste zu sein. Was würden Sie vorschlagen?

Die nächsten Wochen werden für mich ziemlich stressig. Danach würde ich mich jedoch sehr freuen, an der Implementierung einer aktuellen Offline-First-Lösung für Apollo mitzuwirken – sei es eine neue Version des apollo-offline Pakets oder so etwas wie apollo-link-offline .

Danke @MLPXBrachmann!
Ich denke, dass das optimistische Abrufen mit fetchPolicy gesteuert werden sollte - wenn ich nicht möchte, dass etwas aus dem Cache kommt, sollte ich in der Lage sein, network-only .

@lachenmayer @MLPXBrachmann

Ich bin mehr als bereit und bereit, einen Beitrag zu leisten.

Auch ich suche nach Optionen, um Offline-Verhalten in einer Apollo-App zu implementieren. Der Ansatz von @lachenmayer sieht super vielversprechend aus, aber da er auf apollo-link- beibehalten. Wenn die Seite aktualisiert wird, werden also alle Daten, die nicht an den Server übergeben wurden verworfen (ich gehe davon aus, dass das bei Reactive-Native dasselbe ist, wenn die App angehalten wird). Gibt es zu diesem Aspekt Arbeit oder zumindest Diskussion?

@nicocrm Ich dreht sich die Diskussion um den Offline-Support hauptsächlich um dieses Thema. Ich denke, apollo selbst hat im Moment andere Prioritäten, also sollten wir ein Community-Projekt erstellen apollo-link-offline . Dies wird hoffentlich zu mehr Diskussionen und Fortschritten führen als jetzt 😄

@benseitz Ich bin definitiv dafür. Das Interesse an der Funktion ist groß, daher bin ich sicher, dass es Platz für ein Community-Projekt gibt - solange ich bestehende Bemühungen nicht dupliziere oder fragmentiere, kann ich ein neues Team und Repo für apollo-link-offline erstellen und alle Interessierten einladen . Ich habe ein gewisses persönliches Interesse sowie einen Kunden, der wirklich auf dieses Feature drängt, also werde ich einige Stunden Zeit haben, um darauf zu brennen. Ich werde im apollo-offline-Repository fragen, ob sie die Führung übernehmen möchten, da sie viel mehr Erfahrung haben.

Ich habe definitiv auch persönliches Interesse daran - würde mich freuen, mit Ihnen auf diesem @nicocrm weiter zu chatten. Ich habe bisher keine verlorenen Anfragen bei Reactive-Native bemerkt, aber ich habe das ganze Zeug nicht wirklich richtig getestet (bisher nur mit Abfragen und es scheint, dass alles gut läuft).

Ich denke, es wäre sinnvoll, dafür ein Repo zu starten. @MLPXBrachmann , der apollo-offline erwähnte, dass er in den nächsten Wochen keine Zeit haben wird, um apollo-offline zu verbessern, und ich glaube, es ist am sinnvollsten, es apollo-link-offline .

Ich glaube nicht, dass es irgendeinen Code gibt, der von apollo-offline wiederverwendbar sein wird, da er sehr redux-spezifisch ist.

@nicocrm da stimme ich dir sehr zu. Anhaltende Abfragen/Mutationen in der Warteschlange sollten definitiv etwas sein, um das sich ein potenzieller apollo-link-offline kümmert.

@benseitz Ich denke auch, dass es eine großartige Idee wäre, apollo-link-offline als Gemeinschaftsleistung zu starten und würde mich sehr gerne an der Entwicklung beteiligen.

@lachenmayer Du hast absolut Recht, die Menge an Code, die apollo-offline und das geplante apollo-link-offline Paket teilen, wird wahrscheinlich so gut wie gar nicht sein. Ich denke jedoch, dass viele der zugrunde liegenden Konzepte des ersteren immer noch gelten, wenn ein Offline-Toolkit im Apollo 2.0-Universum entwickelt wird.

Auf jeden Fall würde ich mich freuen, Ideen für apollo-link-offline zu diskutieren, Feedback zur Umsetzung zu geben und - sobald mein Terminplan etwas freier wird - auch etwas Code beisteuern.

@MLPXBrachmann @lachenmayer @nicocrm Das klingt nach dem richtigen Weg!
Da kann jeder einen öffentlichen Kanal auf dem Apollo Slack eröffnen. Ich würde vorschlagen, einen mit dem Namen apollo-link-offline öffnen. Vielleicht erleichtert dies die Kommunikation zwischen uns ein wenig. Alle wichtigen Entscheidungen sollten weiterhin in GitHub Issues dokumentiert werden.

Sind Sie damit einverstanden, dass ich sowohl den Repo- als auch den Slack-Kanal öffne oder möchte das einer von Ihnen?

Auf jeden Fall, danke!

Ich habe Sie drei als Mitarbeiter zum Repo hinzugefügt. Und du kannst dem #apollo-link-offline Kanal in Apollo Slack beitreten

Natürlich ist jeder eingeladen, am GitHub Repo mitzuarbeiten und auf Slack zu diskutieren :)
Ich bin sehr aufgeregt 💯

Für diejenigen von Ihnen, die über eine Google-Suche hierher kommen, habe ich eine Zusammenfassung aller bestehenden Offline-Technologien verfasst, die heute für Apollo Client 2.0 verfügbar sind.

https://github.com/benseitz/apollo-link-offline/issues/1#issuecomment -371678922

Arbeitet Apollo an einem AWS AppSync-Äquivalent? Wir haben bereits einen GraphQL-Server und benötigen Offline-Client-Caching für Abfragen und Mutationen, die unseren Server verwenden, keine AWS-Lösungen (dh Lamda, DynamoDB, Elastic Search).

hoffe es funktioniert.

@masull Das wäre absolut erstaunlich. Ich habe es versucht und dachte nicht, dass Firebase oder Parse-Plattform für mich funktionieren, also wäre es großartig, diese Funktion zu haben.
Es fällt mir schwer, alles mit vielen Paketen einzurichten ... überhaupt kein Spaß :)