Apollo-link: [apollo-link-offline]あなたの考えは何ですか？

典型的なユースケースとして何を考えますか？

オフラインアプリとして：

• すべてのgraphqlリクエストがキューに追加されます。 （キャッシュに保存できます）。
• アプリケーションがオンラインシグナルを受信すると、前のリクエストを再送信するようにリンクに通知します。

私はそれがこのように使われていると想像します：

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();
  }
});

これは素晴らしい機能だと思います。 私がそれが潜在的に起こっていると思う方法は、オフラインで使用する必要がある一連のクエリとミューテーションをApollo-link-offlineに定義させることです。

それらが定義されると、アプリケーションのバックグラウンドで、クエリからすべてのデータをフェッチし、それらをローカルストレージに保存できます。 ミューテーションの場合、オフラインで作成されたデータを保存できるように、ローカルストレージに作成されたすべてのフィールドが必要になります。

このようにして、データをローカルキャッシュに保存しながら、オフラインでも機能を実行できます。
Service Workerにリンクできれば、GoogleのPWAテストにも合格します。
その後、アプリがオンラインに戻ると、ローカルキャッシュで発生したすべてのミューテーションをAPIに戻すことができます。

明らかに、何らかの形の同時実行保護を実施する必要があります。

私の心配は、ユーザーA（オフライン）がテーブルXを更新し、ユーザーB（オンライン）がユーザーAがオフラインのときにテーブルXを更新したことです。 ここでは、何らかの形式の同時実行ルールが必要になります。 日付駆動型である可能性があると思いますが、ユーザーBが気付かないうちにユーザーAがユーザーBのデータを上書きした場合、問題は解決しません。

または、ミューテーションに失敗して、オンラインに戻ったときにユーザーに手動で更新させることもできます。

Apollo Client 2は素晴らしいですが、この機能は絶対的な犬の大騒ぎになります

私もこれが大好きです。 1.0のReduxストアでこれに取り組むためのさまざまな試みがあったことは知っていますが、一貫したアプローチでApollo2.0エコシステムの完全な市民にすることは非常に素晴らしいことです。

ここで取り上げた内容のほとんどは、すでに私には非常に理にかなっています。基本的には、データをローカルストレージに永続化し、事後にそこからApolloにヤンクしたいと思います。 第二に、突然変異をキューに入れること。

一種の第3の目標として、バックグラウンドでさらに多くのデータを吸い込めることも素晴らしいことであり、私が関係なくやりたいと思っていることです。 私は実際には、ユーザーのデータのほぼすべてをローカルにも保存して、一般的なクエリ操作をはるかに高速化し、ネットワークを許可して完全な精度で再水和したいと考えています。 ですから、特にService WorkerがSafariでようやく技術プレビューに登場することで実行可能になり始めているので、その熱心な後の負荷の角度に対するある種の解決策は素晴らしいでしょう。

私もこれに興奮しています。 @danieljvdm apollo-clientリポジトリの問題で、永続性について少し有利なスタートを切りました。

RetryLinkはネットワークエラーと再試行の管理に役立つと思いますが、 redux-offlineのようなある種のフォールオフを見たいと思います。

これはかなりクールです。 @ 2WheelCoderが参照した問題は、完全なオフラインサポート（キューイングクエリ/ミュー

それでも、開始してその上に構築するのに適切な場所である可能性があります。 その問題で私が指摘したのは、現在、キャッシュの変更を監視する良い方法がないということです。 私は実際に今日の初めに@ 2WheelCoderの最初の提案を実装しようとしましたが、同様の問題に遭遇しました。 「ストアの変更を監視する」ためのApolloLinkの作成に関する問題は、クライアントアクションとその後のキャッシュ書き込みの間のコンテキストでのみ存在することです。 したがって、リクエストが送信される前にインターセプトし（ミドルウェア）、キャッシュに書き込まれる前にインターセプトすることができます（アフターウェア）が、いつ書き込まれたかはわかりません-推測することしかできません（現在のハックは1000ミリ秒のタイムアウトです） ）。

オフライン永続性にリンクを使用する場合のもう1つの致命的な欠陥は、サブスクリプションが考慮されないことです。 サブスクリプションリンクは、サブスクリプションが開かれたときにのみ起動し、後続のイベントでは起動しません（これを行う方法がないのでしょうか？）。

これは基本的に私が今いるところです、そして私はかなり立ち往生しています-私はさらに取得するために私はapollo-cache-inmemoryへのPRを開かなければならないかもしれないと思います。

@danieljvdm私は同じ場所にいます。同じ問題が発生した後、キャッシュで直接永続性を処理することは理にかなっていると思います。 オブザーバブルはリクエストの後、（通常は）キャッシュが更新される前に完了するため、HttpLinkはそれに適していません。

apollo-cache-inmemoryでPRを開く価値があるかもしれませんが、それを新しいプロジェクトにフォークする方がよいのではないかと思います。 キャッシュとリンクに関するApollo2のモジュール性は、別の種類のキャッシュが必要な場合は、それを構築するだけでよいことを示唆しているようです。 たぶん、apollo-clientの問題は次のステップです（apollo-cache-inmemoryには独自のリポジトリがあるとは思いません）？

こちらのリンクから少し話題から外れてしまったことをお詫びします。

@holmanサファリテックプレビューでサービスワーカーについてのリファレンスがありますか？

@seduboisそれは技術プレビュー中ですが、まだまだかなりのことがあります。

@ 2WheelCoder新しいキャッシュのapolloクライアントへのPRのアイデアが好きです。 おそらくapollo-offline-cacheはapollo-cache-inmemory拡張できますか？ 私はそれに取り組むのを喜んで手伝いたいと思います。 そこで問題を開きたいですか？

@ 2WheelCoder @danieljvdm永続性のためにLocalForageを使用するのはどうですかhttps://github.com/localForage/localForage皆さんがPRを開いたら、私は喜んで手を貸します

@danieljvdmええ、PRを

@EishpirateLocalForageが素晴らしいことに間違いなく同意します。 redux-persistがストアを保存する方法はかなり堅実で、おそらくapollo-offline-cache従うべき適切なパターンとして機能できると思います。

皆さん、私はreduxpersistパッケージを使用してストアデータをreactnativeAsyncStorageに保存しています。 私は今これをどのように行うのですか？ 何か案が？

@Eishpirate ： https://github.com/localForage/localForage/wiki/Supported-Browsers-Platforms

apolloのオフライン機能がアプリで機能しないのは非常に悲しいことです。

@timLoewelそれは非常に良い点です。 ReactNativeほど先を考えていませんでした。 明示的にそうなるとは思わないでください。

これにより、今後予期しない問題が発生する可能性があります。 車輪の再発明をせずに実行可能な代替案があるかどうかはわかりませんが

このディスカッションに関連する可能性のある興味深い記事https://blog.logrocket.com/building-an-offline-first-app-with-react-and-rxdb-e97a1fa64356?t=now

オフラインデータベースとしてrxdbを使用することは本当に有望に見えます。 これは、React、React-Native、Vue、Angular、ほとんど最も人気のあるオプションと互換性があります。

しかし、私が見つけた問題は、PouchDB（CouchDBの派生物）のようなnoSQLデータベースと同期する必要があるということです。 私のユースケースでは、リレーショナルSQLデータベース（Postgres）を使用しており、すべてのデータ検証はデータベースレベルで行われます。 このシステムを使用する必要がある場合は、jsonschemaを介して検証を維持する必要があります。

それはDRYの原則に従わず、間違いなく問題を引き起こします。

私が見つけたもう一つの選択肢はKintoあるhttp://docs.kinto-storage.org/en/stable/index.htmlのPostgresで動作しますので、rxdbを導入することの複雑さの余分な層のいくつかを避けるべきです。 KintoはHTTPを使用しているため、理論的にはApollo-link-httphttps ：//github.com/apollographql/apollo-link/tree/master/packages/apollo-link-httpにプラグインするだけで済み

多くの作業がキャッシングに関連しているように思われます。

reduxはどうですか？ （私は真剣です）

apollo-offline作業に基づくapollo-link-offlineパッケージと...
apollo-cache-reduxパッケージ。 apollo-offlineと同じように、redux-offline / redux-persistを使用します。

Apolloは、デフォルトの汎用ソリューションとしてinmemory-cacheを作成しました-なぜ彼らが別のライブラリとそれほど密接に結び付けられたくないのか理解できます。 しかし、redux / redux-offline / redux-persisソリューションは非常にテスト済みです...それでも、優れた選択肢です。 開発は3つすべてで非常に活発です。

編集：@rportugalのおかげで、 apollo-cache-reduxが存在するようになりました

@giautm少し前に私の小さなプロジェクトについてあなたが説明したことをほぼ正確に実装し、それを本当に単純なパッケージとして公開することにしました： apollo-link-queue 。 改善のアイデアがあれば、提案や貢献をお願いします。

この問題の状態を教えてください。 Apolloからのもので、Reduxオフラインとは関係のないオフラインのものに使用できるものはありますか？

@smithaitufe 、
はい、 apollo-cache-persistを使用できます。

@ Gregor1971
この参照をありがとう。 私はそれを試してみて、私の観察を提出します。
表面的には、クールで実装が簡単に見えます。

これはapollo-link-queueとどのように異なり

皆さん、私はapollo-offlineと同様の動作をするreact-nativeの基本的な実装をまとめようとしました。
（https://github.com/Malpaux/apollo-offline/issues/14にpingを送信）

あなたはこの要点でそれをチェックすることができます： //gist.github.com/lachenmayer/2e364a5ca9ae0918eb032867d0c6720d

それは次の組み合わせです：

• apollo-link-queue 、
• apollo-link-retry 、
• およびカスタムoptimisticFetchLink関数。

デバイスがオフラインになると、リクエストはキューに入れられ、オンラインに戻るとキューから外されます。 （ apollo-link-queue ）

ネットワークエラーで失敗したリクエストはすべて再試行されます（現在は無限に）。 （ apollo-link-retry ）
これは、デバイスがオフラインであるか、バックエンドに到達できない（たとえば、デバイスがダウンしている場合）ことが原因である可能性があることに注意してください。

ただし、キャッシュからクエリを解決できる場合は、再試行されず、代わりにキャッシュ内のデータが応答として使用されます。 これはoptimisticFetchLink関数で実装されます。

私の意見では、この「楽観的なフェッチ」動作はapollo-offlineの最も重要な部分の1つであり、将来のapollo-link-offline実装はこれをサポートする必要があります。 これにより、ユーザーは、データがフェッチされて永続化されている限り、オフラインでも通常どおりアプリを使用できます。 私の意見では、これはnetwork-and-cacheフェッチポリシーのデフォルトの動作であるはずですが、残念ながら、これがすぐに変更されるようには見えません（https://github.com/apollographql/react-apollo/issues/を参照） 604＃issuecomment-355648596）。

要旨をofflineLink.jsとして保存すると、次のように使用できます。

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,
}

既知の問題/不足しているビット

• 今のところ、これはreact-nativeでのみ機能します。 このクロスプラットフォームを作成するには、 isOnlineチェックを抽象化する必要があります。
• キャッシュに部分的な応答しかない場合は、応答が不完全であることを通知する拒否されたプロミスがどこかに表示されます。 私はまだそれを修正する方法、または実際にapollo-offlineがこれをどのように解決するかを調べていません。 これを修正してみたい場合は、これに関するポインタをいただければ幸いです。
• 現在、再試行設定を変更することはできません。これは、追加の構成パラメーターとして追加する必要があります。
• 楽観的なフェッチを制御することはできません。 これは、クエリごとに個別に設定できるはずです。 私はこれのapollo-offlineの実装（ {__online_: true}クエリ変数の設定）の大ファンではありませんが、これを行うには間違いなく何らかの方法があるはずです。
• 明らかにテストもありません。

これに関する解決策を探している人は誰でもこれを試していただければ幸いです。そうすれば、これをタイピング、テスト、ドキュメントなどを備えた適切なnpmモジュールに変えることができます。 この振る舞いは私の意見では非常に重要であり、apollo-client2がまだこれに対する適切な解決策を持っていないのは本当に残念です。

いいね✌️

@smithaitufe 、

これはapollo-link-queueとどう違うのですか？

apollo-link-queueは、接続ステータスに基づいてインテリジェントな処理を実行しているように見えます。 apollo-cache-persistはキャッシュを保存します。 たとえば、ユーザーが接続を切断した状態でアプリを起動して実行できるようにします。 キャッシュを永続化しないと、アプリを起動するために接続が必要になります。

上記の@lachenmayerのソリューション（apollo-link-queueを使用）と永続的なキャッシュの両方、またはさらに良い方法が必要になる可能性があります。 （私たちはリンクリポジトリでチャットしているので、ここでの焦点のほとんどはそれにあります）

@lachenmayer一見すると、あなたのアプローチは非常に魅力的に見えます。

apollo-offlineの楽観的なフェッチ機能のようなものの必要性について私はあなたに絶対に同意します。 それ（またはむしろそれの欠如）は、主に私がapollo-offlineを始めるきっかけとなったもの

私自身、 apollo-offlineで楽観的なフェッチ機能を選択的に有効/無効にする方法を実装する方法に完全に満足していません。 クエリ変数は最初の選択肢ではありませんでしたが、最も実用的なもののようでした。 何を提案しますか？

次の数週間は私にとってかなりストレスになるでしょう。 その後、Apolloの最新のオフラインファーストソリューションの実装に貢献できれば幸いです。これは、 apollo-offlineパッケージの新しいバージョンかapollo-link-offlineようなものかもしれません。

ありがとう@MLPXBrachmann！
楽観的なフェッチはfetchPolicyを使用して制御する必要があると思います。キャッシュから何も取得したくない場合は、 network-onlyを使用できるはずです。

@lachenmayer @MLPXBrachmann

私は準備ができており、貢献する用意があります。

私もApolloアプリでオフライン動作を実装するためのオプションを探しています。 @lachenmayerからのアプローチはテーションは永続化されないため、ページが更新されると、サーバーにコミットされていないデータは次のようになります。破棄されました（アプリが一時停止されている場合、react-nativeでも同じことだと思います）。 その側面について何か仕事や少なくとも議論はありますか？

@nicocrmなるほど...現時点では、オフラインサポートに関する議論は主にこの問題にあります。 現在、アポロ自体には他の優先事項があると思うので、コミュニティプロジェクトapollo-link-offlineを作成する必要があります。 これにより、今よりも多くの議論と進歩がもたらされることを願っています😄

@benseitz私は間違いなくそれに賛成です。 この機能には多くの関心が寄せられているため、コミュニティプロジェクトの余地があると確信しています。既存の取り組みを複製したり断片化したりしない限り、新しいチームを作成してapollo-link-offlineのリポジトリを作成し、関心のあるすべての人を招待できます。 。 私は個人的な興味を持っているだけでなく、クライアントがその機能を本当に求めているので、それを燃やすのに数時間かかります。 apollo-offlineリポジトリで、経験が豊富なため、主導権を握りたいかどうかを尋ねます。

私も間違いなくこれに個人的な興味を持っています-この@nicocrmであなたとさらにチャットできれば幸いです。 これまでのところ、react-nativeでリクエストが失われたことに気づいていませんが、これらすべてを適切にテストしていません（これまでのクエリでのみ、すべてを正常に実行できるようです）。

このためのレポを開始するのは理にかなっていると思います。 上記のapollo-offline作成したapollo-offline改善に費やす時間がないため、 apollo-link-offlineと呼ぶのが最も理にかなっていると思います。

apollo-offlineから再利用できるコードは、非常にredux固有であるため、ないと思います。

@nicocrm私はあなたに非常に同意します。 キューに入れられたクエリ/ミューテーションを永続化することは、潜在的なapollo-link-offlineが処理するものであることは間違いありません。

@benseitz私も、コミュニティの取り組みとしてapollo-link-offlineを開始するのは素晴らしい考えであり、その開発に参加したいと思っています。

@lachenmayerあなたは絶対に正しいです、 apollo-offlineと計画されたapollo-link-offlineパッケージによって共有されるコードの量はおそらくほとんどないでしょう。 ただし、前者の基本的な概念の多くは、Apollo2.0ユニバースでオフラインツールキットセットを開発するときにも当てはまると思います。

いずれにせよ、 apollo-link-offlineアイデアについて話し合い、実装に関するフィードバックを提供し、スケジュールが少し解放されたらすぐに、いくつかのコードも提供したいと思います。

@MLPXBrachmann @lachenmayer @nicocrmこれはそうするための正しい方法のように聞こえます！
誰でもApolloSlackで公開チャンネルを開くことができるので。 apollo-link-offlineという名前のファイルを開くことをお勧めします。 たぶん、これは私たちの間のコミュニケーションを少し簡単にします。 重要な決定はすべて、GitHubの問題に文書化する必要があります。

レポとスラックの両方のチャネルを開いても大丈夫ですか、それともどちらかがやりたいですか？

確かに、ありがとう！

共同作業者として3人をリポジトリに追加しました。 そして、 Apollo Slackの#apollo-link-offlineチャンネルに参加できます

もちろん、誰もがGitHubリポジトリで共同作業し、Slackについて話し合うように招待されています:)
とても興奮しています💯

Google検索からここにアクセスする方のために、Apollo Client2.0で現在利用可能なすべての既存のオフラインテクノロジーの概要をまとめました。

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

ApolloはAWSAppSyncと同等のものに取り組んでいますか？ すでにGraphQLサーバーがあり、AWSソリューション（つまり、Lamda、DynamoDB、Elastic Search）ではなく、サーバーを使用したクエリとミューテーションのためのオフラインクライアントキャッシュが必要です。

それが機能することを願っています。

@masullそれは絶対に素晴らしいでしょう。 Firebaseや解析プラットフォームが機能するとは思わなかったので、この機能を使用するとすばらしいでしょう。
たくさんのパッケージですべてをセットアップするのに苦労しています...まったく面白くありません:)