Apollo-link: [apollo-link-offline] Apa idemu?

Apa yang akan Anda pertimbangkan sebagai kasus penggunaan biasa?

Sebagai aplikasi offline:

• Semua permintaan graphql ditambahkan ke antrian. (dapat disimpan dalam cache).
• Ketika aplikasi menerima sinyal online, itu menginformasikan tautan untuk mengirim ulang permintaan sebelumnya.

Saya membayangkan itu digunakan seperti ini:

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

Saya pikir ini akan menjadi fungsionalitas yang luar biasa. Cara saya melihatnya berpotensi terjadi, adalah meminta Apollo-link-offline menentukan serangkaian Pertanyaan dan Mutasi yang perlu digunakan secara offline.

Setelah itu didefinisikan, di latar belakang aplikasi, kita bisa mengambil semua data dari Kueri dan menyimpannya di penyimpanan lokal. Untuk Mutasi, kami membutuhkan semua bidang yang dibuat di penyimpanan lokal sehingga kami dapat menyimpan data apa pun yang dibuat secara offline.

Dengan cara ini kita tetap dapat melakukan fungsionalitas saat offline sambil menyimpan data di cache lokal.
Kami juga akan lulus tes PWA Google jika kami dapat menautkan ke Service Worker
Kemudian ketika aplikasi kembali online, maka semua mutasi yang terjadi pada cache lokal dapat diteruskan kembali ke API.

Jelas perlu ada beberapa bentuk perlindungan Concurrency di tempat.

Kekhawatiran saya adalah Pengguna A (offline) memperbarui Tabel X sementara Pengguna B (online) memperbarui Tabel X saat Pengguna A offline. Kami membutuhkan beberapa bentuk aturan Concurrency di sini. Saya kira itu bisa didorong oleh tanggal, tetapi itu tidak menyelesaikan masalah jika Pengguna A menimpa data Pengguna B tanpa disadari oleh Pengguna B.

Atau kita bisa saja gagal Mutasi dan membiarkan Pengguna memperbarui secara manual saat kembali online.

Apollo Client 2 luar biasa, tetapi bagian dari fungsionalitas ini akan menjadi omong kosong anjing mutlak

Saya akan menjadi penggemar berat ini juga. Saya tahu ada berbagai upaya untuk mengatasi ini dengan toko Redux 1.0, tetapi menjadikannya warga penuh ekosistem Apollo 2.0 dengan pendekatan yang konsisten akan sangat luar biasa.

Sebagian besar dari apa yang dibahas di sini sudah sangat masuk akal bagi saya - pada dasarnya saya ingin menyimpan data saya ke penyimpanan lokal, dan kemudian menariknya dari sana ke Apollo setelah fakta. Kedua, antrian mutasi.

Sebagai semacam tujuan tersier, mampu menyedot lebih banyak data di latar belakang juga akan bagus, dan sesuatu yang akan saya coba lakukan terlepas dari itu. Saya sebenarnya ingin menyimpan hampir semua data pengguna secara lokal juga, hanya untuk membuat operasi kueri umum lebih cepat, dan kemudian rehidrasi untuk akurasi penuh, jaringan memungkinkan. Jadi semacam solusi untuk sudut yang penuh semangat untuk nanti akan sangat bagus, terutama karena Pekerja Layanan mulai menjadi layak dengan Safari yang akhirnya memilikinya dalam pratinjau teknologi.

Saya juga bersemangat tentang ini. @danieljvdm Sedikit lebih awal tentang kegigihan dalam masalah di repo apollo-client .

Saya pikir RetryLink akan berguna untuk mengelola kesalahan jaringan dan mencoba lagi, meskipun saya ingin melihat semacam kesalahan seperti yang dimiliki redux-offline .

Ini cukup keren. Masalah yang dirujuk oleh @2WheelCoder adalah pendekatan awal dan mungkin naif yang lebih diarahkan untuk mempertahankan cache daripada dukungan offline penuh (antri kueri/mutasi dan semacamnya).

Itu masih bisa menjadi tempat yang layak untuk memulai dan membangun di atas. Apa yang saya tunjukkan dalam masalah itu adalah bahwa saat ini saya tidak memiliki cara yang baik untuk memantau cache untuk perubahan. Saya sebenarnya mencoba menerapkan saran awal @2WheelCoder sebelumnya hari ini tetapi mengalami masalah serupa. Masalah dengan membuat ApolloLink untuk "memantau perubahan toko" adalah bahwa ia hanya hidup dalam konteks antara tindakan klien dan kemudian penulisan cache berikutnya. Jadi saya dapat mencegat permintaan sebelum keluar (middleware) dan mencegatnya sebelum ditulis ke cache (afterware) tetapi saya tidak tahu kapan _telah_ ditulis - saya hanya bisa menebak (retas saya saat ini adalah batas waktu 1000ms ).

Kelemahan fatal lainnya dengan menggunakan tautan untuk kegigihan offline adalah bahwa tautan itu tidak memperhitungkan langganan. Tautan berlangganan hanya akan aktif ketika langganan dibuka, bukan pada acara berikutnya (mungkin ada cara untuk melakukan ini yang saya lewatkan?).

Ini pada dasarnya di mana saya sekarang, dan saya cukup buntu - saya pikir untuk melangkah lebih jauh saya mungkin harus membuka PR ke apollo-cache-inmemory.

@danieljvdm Saya berada di tempat yang sama dan saya pikir masuk akal untuk menangani kegigihan secara langsung di cache setelah mengalami masalah yang sama dengan yang Anda lakukan. HttpLink tidak cocok untuk itu karena yang dapat diamati selesai setelah permintaan tetapi (biasanya) sebelum cache diperbarui.

Meskipun mungkin layak untuk membuka PR di apollo-cache-inmemory, saya juga bertanya-tanya apakah akan lebih baik untuk membaginya menjadi proyek baru. Modularitas Apollo 2 di sekitar cache dan tautan tampaknya menunjukkan bahwa jika Anda memerlukan jenis cache yang berbeda, Anda bisa membuatnya. Mungkin masalah pada apollo-client adalah langkah selanjutnya (saya tidak berpikir apollo-cache-inmemory memiliki repo sendiri)?

Maaf untuk mendapatkan sedikit di luar topik dari tautan di sini.

@holman apakah Anda memiliki referensi tentang pekerja layanan di pratinjau teknologi safari?

@sedubois itu turun (agak tiba-tiba) satu atau dua bulan yang lalu. Ini dalam pratinjau teknologi , tetapi masih ada sedikit yang harus dilakukan .

@2WheelCoder Saya suka ide PR untuk meminta klien untuk cache baru. Mungkin apollo-offline-cache yang dapat memperpanjang apollo-cache-inmemory ? Saya bersedia membantu mengerjakannya. Ingin membuka masalah di sana?

@2WheelCoder @danieljvdm bagaimana dengan menggunakan LocalForage untuk kegigihan https://github.com/localForage/localForage Jika kalian membuka PR, saya bersedia membantu

@danieljvdm Ya, saya akan membuka masalah jika Anda ingin mendapatkan PR. Saya tidak punya banyak waktu selama satu setengah minggu ke depan, tetapi saya senang untuk terjun setelah itu.

@Eishpirate Pasti setuju LocalForage hebat. Saya pikir cara redux-persist mengelola menyimpan toko cukup solid dan mungkin dapat bertindak sebagai pola yang layak untuk diikuti dalam apollo-offline-cache .

Teman-teman, saya menggunakan paket redux bertahan untuk menyimpan data toko dalam reaksi asli AsyncStorage. Bagaimana saya melakukan ini sekarang? Ada ide?

@Eishpirate : apakah localforage berfungsi untuk reaksi asli? Melihat bagan kompatibilitas perpustakaan, saya tidak dapat menemukan apa pun tentang reaksi asli. https://github.com/localForage/localForage/wiki/Supported-Browsers-Platforms

Akan sangat menyedihkan jika fitur offline apollo tidak berfungsi untuk aplikasi..

@timLoewel itu

Ini dapat menyebabkan masalah tak terduga lebih lanjut. Meskipun tidak yakin apakah ada alternatif yang layak tanpa harus menemukan kembali roda

Artikel menarik yang mungkin relevan dengan diskusi ini https://blog.logrocket.com/building-an-offline-first-app-with-react-and-rxdb-e97a1fa64356?t=now

Tampaknya sangat menjanjikan menggunakan rxdb sebagai database offline. Ini kompatibel dengan React, React-Native, Vue, Angular, opsi paling populer.

Masalah yang saya temukan adalah perlu disinkronkan dengan database noSQL seperti PouchDB (turunan dari CouchDB). Dalam kasus penggunaan saya, saya menggunakan database SQL relasional (Postgres) dan semua validasi data saya terjadi di tingkat database. Jika saya harus menggunakan sistem ini, maka saya harus mempertahankan validasi melalui jsonschema.

Itu tidak mengikuti prinsip KERING, dan pasti akan menimbulkan masalah.

Opsi lain yang saya temukan adalah Kinto http://docs.kinto-storage.org/en/stable/index.html yang bekerja dengan Postgres sehingga harus menghindari beberapa lapisan kompleksitas tambahan yang akan diperkenalkan rxdb. Kinto menggunakan HTTP, jadi secara teoritis kami hanya dapat menghubungkannya ke Apollo-link-http https://github.com/apollographql/apollo-link/tree/master/packages/apollo-link-http

Kedengarannya seperti banyak pekerjaan akan terkait dengan caching.

Bagaimana dengan redux? (Aku serius)

Paket apollo-link-offline , berdasarkan pekerjaan apollo-offline dan...
Paket apollo-cache-redux . Gunakan redux-offline/redux-persist seperti yang dilakukan apollo-offline sekarang.

Apollo membuat inmemory-cache sebagai default, solusi umum - saya bisa mengerti mengapa mereka tidak ingin terikat begitu dekat dengan perpustakaan lain. Tetapi solusi redux/redux-offline/redux-persis sangat teruji... itu masih merupakan pilihan yang bagus. Pengembangan sangat aktif untuk ketiganya.

EDIT: apollo-cache-redux ada sekarang, terima kasih kepada @rportugal

@giautm Saya telah menerapkan hampir persis apa yang Anda gambarkan untuk proyek kecil saya beberapa waktu lalu, dan memutuskan untuk menerbitkannya sebagai paket yang sangat sederhana: apollo-link-queue . Jika ada di antara Anda yang memiliki ide untuk perbaikan, saya ingin mendapatkan saran atau kontribusi Anda.

Tolong bagaimana keadaan masalah ini? Apakah ada sesuatu yang bisa kita gunakan untuk barang offline yang berasal dari Apollo dan tidak terkait dengan Redux Offline?

@smithaitufe ,
Ya, Anda dapat menggunakan apollo-cache-persist .

@Gregor1971
Terima kasih untuk referensi ini. Saya akan mencobanya dan menyerahkan pengamatan saya.
Pada tampilan permukaan, terlihat keren dan mudah diterapkan.

Bagaimana ini berbeda dari apollo-link-queue

Hai teman-teman, saya telah mencoba mengumpulkan implementasi dasar untuk react-native yang memiliki perilaku yang mirip dengan apollo-offline .
(ping ke https://github.com/Malpaux/apollo-offline/issues/14)

Anda dapat memeriksanya di Intisari ini: https://Gist.github.com/lachenmayer/2e364a5ca9ae0918eb032867d0c6720d

Ini adalah kombinasi dari:

• apollo-link-antrian ,
• apollo-link-coba lagi ,
• dan fungsi kustom optimisticFetchLink .

Saat perangkat offline, permintaan akan diantrekan, dan tidak akan diantrekan saat kembali online. ( apollo-link-queue )

Setiap permintaan yang gagal dengan kesalahan jaringan akan dicoba lagi (saat ini tidak terbatas). ( apollo-link-retry )
Perhatikan bahwa ini bisa jadi karena perangkat sedang offline, atau backend tidak dapat dijangkau (mis. jika sedang down).

Namun, jika kami dapat menyelesaikan kueri dari cache, itu tidak akan dicoba lagi, dan sebagai gantinya data dalam cache akan digunakan sebagai respons. Ini diimplementasikan dalam fungsi optimisticFetchLink .

Menurut pendapat saya, perilaku "pengambilan optimis" ini adalah salah satu bagian terpenting dari apollo-offline, dan implementasi apollo-link-offline masa mendatang harus mendukung ini. Ini memungkinkan pengguna untuk tetap menggunakan aplikasi seperti biasa saat offline, selama data telah diambil & disimpan di beberapa titik. Menurut pendapat saya, ini harus menjadi perilaku default dari network-and-cache fetch policy , tapi sayangnya sepertinya ini tidak akan berubah dalam waktu dekat (lihat https://github.com/apollographql/react-apollo/issues/ 604#issuecomment-355648596).

Jika Anda menyimpan intinya sebagai offlineLink.js , Anda dapat menggunakannya sebagai berikut:

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

Masalah yang diketahui / bit yang hilang

• Ini hanya berfungsi dengan reaksi asli untuk saat ini. Cek isOnline harus diabstraksikan untuk membuat lintas platform ini.
• Jika Anda hanya memiliki sebagian respons di cache, Anda akan mendapatkan janji yang ditolak di suatu tempat di telepon yang memberi tahu Anda bahwa responsnya tidak lengkap. Saya belum melihat bagaimana cara memperbaikinya, atau bagaimana apollo-offline menyelesaikan ini. Jika Anda ingin mencoba memperbaiki ini, saya akan menghargai setiap petunjuk tentang ini.
• Saat ini Anda tidak dapat mengubah pengaturan coba lagi - ini harus ditambahkan sebagai parameter konfigurasi tambahan.
• Anda tidak memiliki kendali atas pengambilan optimis. Anda harus dapat mengatur ini secara independen untuk setiap kueri. Saya bukan penggemar berat implementasi apollo-offline dari ini (mengatur variabel kueri {__online_: true} ), tetapi pasti ada cara untuk melakukan ini.
• Jelas juga tidak ada tes.

Saya menghargai siapa pun yang mencari solusi untuk ini untuk mencoba ini, dan kami kemudian dapat mengubah ini menjadi modul npm yang tepat dengan pengetikan, tes, dokumen & semuanya. Perilaku ini menurut saya sangat penting, dan sangat disayangkan apollo-client 2 belum memiliki solusi yang tepat untuk ini.

Bagus ️

@smithaitufe ,

Bagaimana ini berbeda dari apollo-link-queue?

Sepertinya apollo-link-queue melakukan hal-hal cerdas berdasarkan status koneksi. apollo-cache-persist menyimpan cache; memungkinkan, misalnya, pengguna untuk memulai dan menjalankan aplikasi Anda saat terputus. Tanpa menyimpan cache, aplikasi Anda memerlukan konektivitas untuk memulai,

Kami mungkin menginginkan keduanya, atau lebih baik lagi, solusi @lachenmayer di atas (yang menggunakan apollo-link-queue) dan cache yang persisten. (kami mengobrol di repo tautan, jadi sebagian besar fokus di sini adalah pada itu)

@lachenmayer Dari tampilan pertama, pendekatan Anda terlihat sangat menarik.

Saya sangat setuju dengan Anda tentang perlunya sesuatu seperti fitur pengambilan optimis apollo-offline . Itu (atau lebih tepatnya kekurangannya) sebagian besar adalah apa yang mengilhami saya untuk memulai apollo-offline .

Saya sendiri tidak cukup puas dengan bagaimana saya harus menerapkan secara selektif mengaktifkan/menonaktifkan fitur pengambilan optimis di apollo-offline . Variabel kueri bukanlah pilihan pertama, tetapi sepertinya yang paling praktis. Apa yang akan Anda usulkan?

Beberapa minggu ke depan akan sangat menegangkan bagi saya. Namun setelah itu, saya akan dengan senang hati berkontribusi pada implementasi solusi offline pertama terbaru untuk Apollo - mungkin itu versi baru dari paket apollo-offline atau sesuatu seperti apollo-link-offline .

Terima kasih @MLPXBrachmann!
Saya merasa bahwa pengambilan optimis harus dikontrol menggunakan fetchPolicy - jika saya tidak ingin apa pun datang dari cache, saya harus dapat menggunakan network-only .

@lachenmayer @MLPXBrachmann

Saya lebih dari siap dan bersedia untuk berkontribusi.

Saya juga mencari opsi untuk menerapkan perilaku offline di aplikasi Apollo. Pendekatan dari @lachenmayer terlihat sangat menjanjikan, tetapi karena bergantung pada apollo-link-retry, mutasi yang belum berhasil diterapkan tidak akan bertahan, jadi jika halaman di-refresh, data apa pun yang belum di-commit ke server akan disimpan. dibuang (saya berasumsi itu adalah hal yang sama pada reaksi asli jika aplikasi ditangguhkan). Apakah ada pekerjaan atau setidaknya diskusi tentang aspek itu?

@nicocrm saya mengerti... Saat ini diskusi seputar dukungan offline sebagian besar dalam masalah ini. Saya pikir apollo sendiri memiliki prioritas lain saat ini, jadi kita harus membuat proyek komunitas apollo-link-offline . Semoga ini akan mengarah pada lebih banyak diskusi dan kemajuan daripada sekarang

@benseitz Saya pasti mendukung itu. Ada banyak minat dalam fitur ini jadi saya yakin ada ruang untuk proyek komunitas - selama saya tidak menduplikasi atau memecah-mecah upaya yang ada, saya dapat membuat tim dan repo baru untuk apollo-link-offline dan mengundang semua yang tertarik . Saya memiliki beberapa kepentingan pribadi serta klien benar-benar mendorong untuk fitur itu jadi saya akan memiliki beberapa jam untuk membakarnya. Saya akan bertanya pada repo apollo-offline untuk melihat apakah mereka ingin memimpin karena mereka memiliki lebih banyak pengalaman.

Saya pasti memiliki minat pribadi dalam hal ini juga - dengan senang hati akan mengobrol lebih lanjut dengan Anda di @nicocrm ini. Saya belum melihat ada permintaan yang hilang sejauh ini pada reaksi-asli tetapi saya belum benar-benar menguji semua hal ini dengan benar (hanya dengan kueri sejauh ini & _tampaknya_ untuk menjalankan semuanya dengan baik).

Saya merasa masuk akal untuk memulai repo untuk ini. @MLPXBrachmann yang membangun apollo-offline disebutkan di atas bahwa dia tidak akan punya waktu untuk dihabiskan untuk meningkatkan apollo-offline dalam beberapa minggu ke depan, dan saya yakin sangat masuk akal untuk menyebutnya apollo-link-offline .

Saya tidak berpikir ada kode yang dapat digunakan kembali dari apollo-offline karena sangat spesifik untuk redux.

@nicocrm Saya sangat setuju dengan Anda. Kueri/mutasi antrean yang bertahan pasti harus menjadi sesuatu yang potensial ditangani oleh apollo-link-offline .

@benseitz Saya juga berpikir itu akan menjadi ide bagus untuk memulai apollo-link-offline sebagai upaya komunitas dan sangat ingin berpartisipasi dalam pengembangannya.

@lachenmayer Anda benar sekali, jumlah kode yang dibagikan oleh apollo-offline dan paket apollo-link-offline direncanakan mungkin hampir tidak ada. Namun saya berpikir, bahwa banyak dari konsep yang mendasari yang pertama masih berlaku ketika mengembangkan perangkat offline yang diatur di alam semesta Apollo 2.0.

Bagaimanapun saya akan dengan senang hati mendiskusikan ide untuk apollo-link-offline , memberikan umpan balik tentang implementasinya dan - segera setelah jadwal saya sedikit kosong - kontribusikan beberapa kode juga.

@MLPXBrachmann @lachenmayer @nicocrm Ini terdengar seperti cara yang tepat untuk melakukannya!
Karena siapa pun dapat membuka saluran publik di Apollo Slack . Saya sarankan membuka yang disebut apollo-link-offline . Mungkin ini membuat komunikasi di antara kami sedikit lebih mudah. Semua keputusan penting tetap harus didokumentasikan di GitHub Issues.

Apakah Anda baik-baik saja dengan saya membuka saluran repo dan slack atau apakah salah satu dari Anda ingin melakukannya?

Yang pasti, terima kasih!

Saya menambahkan kalian bertiga sebagai kolaborator ke Repo . Dan Anda dapat bergabung dengan saluran #apollo-link-offline di Apollo Slack

Tentu saja semua orang diundang untuk berkolaborasi di GitHub Repo dan berdiskusi di Slack :)
Saya sangat bersemangat

Bagi Anda yang tiba di sini dari Pencarian Google, saya telah menulis ringkasan dari semua teknologi offline yang tersedia saat ini untuk Apollo Client 2.0.

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

Apakah Apollo bekerja pada AWS AppSync yang setara? Kami sudah memiliki server GraphQL dan memerlukan caching klien offline untuk kueri dan mutasi menggunakan server kami, bukan solusi AWS (yaitu Lamda, DynamoDB, Elastic Search).

semoga berhasil.

@masull Itu akan sangat luar biasa. Saya mencoba dan tidak berpikir bahwa platform firebase atau parse bekerja untuk saya, jadi memiliki fitur ini akan sangat bagus.
Kesulitan mengatur semuanya dengan banyak paket ... tidak menyenangkan sama sekali :)