Apollo-link: [apollo-link-offline] ما هي فكرتك؟

ما الذي تعتبره حالة الاستخدام النموذجية؟

كتطبيق غير متصل بالإنترنت:

• تتم إضافة جميع طلبات الرسم البياني إلى قائمة الانتظار. (يمكن تخزينها في ذاكرة التخزين المؤقت).
• عندما يتلقى التطبيق الإشارة عبر الإنترنت ، فإنه يبلغ الرابط لإعادة تقديم الطلب السابق.

أتخيل أنه يتم استخدامه على النحو التالي:

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 يحدد مجموعة من الاستعلامات والطفرات التي يجب استخدامها في وضع عدم الاتصال.

بمجرد تحديدها ، في خلفية التطبيق ، يمكننا جلب جميع البيانات من الاستعلامات وتخزينها في التخزين المحلي. بالنسبة للطفرات ، نحتاج إلى جميع الحقول التي تم إنشاؤها في التخزين المحلي حتى نتمكن من تخزين أي بيانات يتم إنشاؤها في وضع عدم الاتصال.

بهذه الطريقة لا يزال بإمكاننا أداء الوظائف أثناء عدم الاتصال بالإنترنت أثناء تخزين البيانات في ذاكرة تخزين مؤقت محلية.
سنجتاز أيضًا اختبارات Googles PWA إذا كان بإمكاننا الارتباط بعاملي الخدمة
ثم عندما يعود التطبيق إلى الإنترنت ، يمكن عندئذٍ تمرير جميع الطفرات التي حدثت في ذاكرة التخزين المؤقت المحلية مرة أخرى إلى واجهة برمجة التطبيقات.

من الواضح أنه يجب أن يكون هناك شكل من أشكال حماية التزامن.

ما يقلقني هو قيام المستخدم أ (غير متصل) بتحديث الجدول X بينما قام المستخدم ب (متصل) بتحديث الجدول X بينما كان المستخدم أ غير متصل. سنحتاج إلى شكل من أشكال قواعد التزامن هنا. أعتقد أنه يمكن تحديد التاريخ ، لكنه لا يحل المشكلة إذا تجاوز المستخدم أ بيانات المستخدم ب دون علم المستخدم ب.

أو يمكن أن نفشل في التحويل والسماح للمستخدم بالتحديث يدويًا عند الاتصال بالإنترنت مرة أخرى.

برنامج Apollo Client 2 مذهل ، لكن هذه الوظيفة ستكون بمثابة أداة تثبيت للكلاب

سأكون معجبًا كبيرًا بهذا أيضًا. أعلم أن هناك محاولات مختلفة لمعالجة هذا الأمر من خلال متجر Redux 1.0 ، ولكن جعله مواطنًا كاملاً في نظام Apollo 2.0 البيئي مع اتباع نهج ثابت سيكون رائعًا جدًا.

معظم ما تمت تغطيته هنا منطقي للغاية بالنسبة لي - في الأساس أريد أن أواصل بياناتي في التخزين المحلي ، ثم أخرجها من هناك إلى Apollo بعد الحقيقة. ثانيًا ، اصطفاف الطفرات.

كنوع من الهدف الثالث ، ستكون القدرة على امتصاص المزيد من البيانات في الخلفية أمرًا رائعًا أيضًا ، وهو أمر سأفعله بغض النظر. أود في الواقع تخزين جميع بيانات المستخدم تقريبًا محليًا أيضًا ، فقط لجعل عمليات الاستعلام الشائعة أسرع بكثير ، ثم إعادة الترطيب للحصول على الدقة الكاملة ، مما يسمح بالشبكة. لذا فإن نوعًا من الحلول لزاوية التحميل المتلهف لوقت لاحق سيكون رائعًا ، خاصة وأن عمال الخدمة قد بدأوا في أن يصبحوا قابلين للتطبيق مع Safari أخيرًا في المعاينة التقنية.

أنا أيضا متحمس لهذا. danieljvdm حصلت على القليل من السبق في المثابرة في مشكلة في -client .

أعتقد أن RetryLink سيكون مفيدًا لإدارة أخطاء الشبكة وإعادة المحاولة ، على الرغم من أنني أرغب في رؤية نوع من التراجع مثل redux-offline .

هذا رائع جدا. المشكلة التي أشار إليها

لا يزال من الممكن أن يكون مكانًا لائقًا للبدء والبناء فوقه. ما أشرت إليه في هذه المشكلة هو أنه ليس لدي حاليًا طريقة جيدة لمراقبة ذاكرة التخزين المؤقت من أجل التغييرات. لقد حاولت بالفعل تنفيذ اقتراح @ 2WheelCoder الأولي في وقت سابق اليوم لكنني واجهت مشكلات مماثلة. تكمن المشكلة في إنشاء ApolloLink من أجل "مراقبة تغييرات المتجر" في أنه يعيش فقط في السياق بين إجراء العميل ثم كتابة ذاكرة التخزين المؤقت اللاحقة. لذا يمكنني اعتراض الطلب قبل أن يخرج (برمجية وسيطة) واعتراضه قبل كتابته في ذاكرة التخزين المؤقت (البرامج اللاحقة) لكنني لا أعرف متى _تم كتابته - لا يمكنني إلا أن أخمن (الاختراق الحالي هو مهلة 1000 مللي ثانية ).

عيب فادح آخر في استخدام رابط للاستمرار في وضع عدم الاتصال هو أنه لا يأخذ في الحسبان الاشتراكات. لن يتم تنشيط ارتباط الاشتراك إلا عند فتح الاشتراك ، وليس في الأحداث اللاحقة (ربما هناك طريقة لفعل ذلك فاتني؟).

هذا هو المكان الذي أكون فيه الآن ، وأنا عالق جدًا - أعتقد أن أتمكن من المضي قدمًا في فتح العلاقات العامة لـ apollo-cache-inmemory.

danieljvdm أنا في نفس المكان وأعتقد أنه من المنطقي التعامل مع المثابرة مباشرة على ذاكرة التخزين المؤقت بعد مواجهة نفس المشكلة التي واجهتها. HttpLink ليس مناسبًا له فقط لأن الملحوظة تكتمل بعد الطلب ولكن (عادةً) قبل تحديث ذاكرة التخزين المؤقت.

في حين أنه قد يكون من المفيد فتح العلاقات العامة على ذاكرة التخزين المؤقت في ذاكرة التخزين المؤقت Apollo-cache-inmemory ، إلا أنني أتساءل أيضًا عما إذا كان من الأفضل تحويله إلى مشروع جديد. يبدو أن نمطية Apollo 2 حول ذاكرة التخزين المؤقت والرابط تشير إلى أنه إذا كنت بحاجة إلى نوع مختلف من ذاكرة التخزين المؤقت ، فيمكنك فقط بناؤها. ربما تكون المشكلة في apollo-client هي الخطوة التالية (لا أعتقد أن لدى apollo-cache-inmemory ريبو خاص به)؟

نعتذر عن الخروج قليلاً عن الموضوع من الروابط هنا.

holman هل لديك مرجع حول عامل الخدمة في معاينة

sedubois انخفض (نوعًا ما فجأة) منذ شهر أو شهرين. إنه قيد المعاينة التقنية ، ولكن لا يزال هناك

@ 2WheelCoder تعجبني فكرة العلاقات العامة لعميل أبولو لذاكرة تخزين مؤقت جديدة. ربما apollo-offline-cache يمكن أن يمتد apollo-cache-inmemory ؟ سأكون على استعداد للمساعدة في العمل على ذلك. تريد فتح قضية هناك؟

@ 2WheelCoderdanieljvdm ماذا عن استخدام LocalForage لاستمرار https://github.com/localForage/localForage إذا يا رفاق فتح PR سأكون على استعداد لتقديم يد المساعدة

danieljvdm نعم ،

Eishpirate أتفق بالتأكيد LocalForage رائع. أعتقد أن الطريقة التي أدار بها redux-persist إدارة حفظ المتجر كانت قوية جدًا ويمكن أن تكون بمثابة نمط لائق يجب اتباعه في apollo-offline-cache .

أيها الناس ، أنا أستخدم حزمة redux persist لحفظ بيانات المخزن في AsyncStorage الأصلي للتفاعل. كيف أفعل هذا الآن؟ اي فكرة؟

Eishpirate : هل يعمل Localforage للتفاعل مع السكان الأصليين؟ بالنظر إلى مخطط التوافق الخاص بالمكتبة ، لا يمكنني العثور على أي شيء حول التفاعل الأصلي. https://github.com/localForage/localForage/wiki/Supported-Browsers-Platforms

سيكون من المحزن جدًا ألا تعمل ميزة Apollo غير المتصلة بالإنترنت مع التطبيقات ..

timLoewel انها نقطة جيدة جدا. لم أفكر حقًا في المستقبل مثل React Native. لا تصدق ذلك صراحة.

قد يتسبب هذا في حدوث مشكلات غير متوقعة في المستقبل. لست متأكدًا مما إذا كان هناك بديل قابل للتطبيق دون الحاجة إلى إعادة اختراع العجلة

مقالة مثيرة للاهتمام يمكن أن تكون ذات صلة بهذه المناقشة https://blog.logrocket.com/building-an-offline-first-app-with-react-and-rxdb-e97a1fa64356؟

يبدو حقًا واعدًا باستخدام rxdb كقاعدة بيانات غير متصلة بالإنترنت. هذا متوافق مع خيارات React و React-Native و Vue و Angular ، وهي الخيارات الأكثر شيوعًا إلى حد كبير.

المشكلة التي أجدها هي أنه يحتاج إلى المزامنة مع قاعدة بيانات noSQL مثل PouchDB (مشتق من CouchDB). في حالة الاستخدام الخاصة بي ، أستخدم قاعدة بيانات SQL علائقية (Postgres) وتحدث جميع عمليات التحقق من صحة البيانات الخاصة بي على مستوى قاعدة البيانات. إذا اضطررت إلى استخدام هذا النظام ، فسأحتاج إلى الحفاظ على التحقق عبر jsonschema.

إنه لا يتبع مبادئ DRY ، وسيقدم بالتأكيد مشكلات.

خيار آخر وجدته هو Kinto http://docs.kinto-storage.org/en/stable/index.html والذي يعمل مع Postgres لذا يجب تجنب بعض طبقات التعقيد الإضافية التي قد يقدمها rxdb. يستخدم Kinto HTTP ، لذلك يمكننا نظريًا توصيله بـ Apollo-link-http https://github.com/apollographql/apollo-link/tree/master/packages/apollo-link-http

يبدو أن الكثير من العمل سيكون مرتبطًا بالتخزين المؤقت.

ماذا عن الاستعادة؟ (أنا جادة)

حزمة apollo-link-offline ، بناءً على عمل apollo-offline و ...
حزمة apollo-cache-redux . استخدم redux-offline / redux-persist تمامًا كما يفعل apollo-offline الآن.

أنشأ Apollo ذاكرة التخزين المؤقت inmemory كحل افتراضي عام - يمكنني أن أفهم سبب عدم رغبتهم في الارتباط بشكل وثيق بمكتبة أخرى. لكن حل redux / redux-offline / redux-persis تم اختباره في المعركة ... لا يزال خيارًا رائعًا. التنمية نشطة للغاية لجميع الثلاثة.

تحرير: apollo-cache-redux موجود الآن ، بفضلrportugal

giautm لقد نفذت إلى حد كبير ما تصفه بالضبط لمشروع صغير خاص بي منذ فترة قصيرة ، وقررت نشره كحزمة بسيطة حقًا: apollo-link-queue . إذا كان لدى أي منكم أفكار للتحسين ، يسعدني الحصول على اقتراحاتكم أو مساهماتكم.

من فضلك ما هي حالة هذه القضية؟ هل هناك شيء يمكننا استخدامه للمواد غير المتصلة بالإنترنت من Apollo ولا يتعلق بـ Redux Offline؟

@ smithaitufe ،
نعم ، يمكنك استخدام apollo-cache-persist .

@ gregor1971
شكرا لهذه الإشارة. سأجربها وأقدم ملاحظاتي.
من حيث المظهر السطحي ، يبدو رائعًا وسهل التنفيذ.

كيف يختلف هذا عن طابور الارتباط أبولو

مرحبًا يا رفاق ، لقد حاولت تجميع تطبيق أساسي للتفاعل الأصلي الذي له سلوك مشابه لـ apollo-offline .
(pinging https://github.com/Malpaux/apollo-offline/issues/14)

يمكنك التحقق من ذلك في هذا الموضوع: https://gist.github.com/lachenmayer/2e364a5ca9ae0918eb032867d0c6720d

إنه مزيج من:

• طابور الارتباط أبولو ،
• أبولو رابط إعادة المحاولة ،
• ووظيفة مخصصة optimisticFetchLink .

عندما ينتقل الجهاز إلى وضع عدم الاتصال ، سيتم وضع الطلبات في قائمة الانتظار ، وستكون غير مصنفة عند الاتصال بالإنترنت مرة أخرى. ( apollo-link-queue )

ستتم إعادة محاولة أي طلب يفشل مع وجود خطأ في الشبكة (حاليًا إلى ما لا نهاية). ( apollo-link-retry )
لاحظ أن هذا قد يكون إما لأن الجهاز غير متصل بالإنترنت ، أو ببساطة لا يمكن الوصول إلى الواجهة الخلفية (على سبيل المثال ، إذا كانت معطلة).

ومع ذلك ، إذا تمكنا من حل الاستعلام من ذاكرة التخزين المؤقت ، فلن تتم إعادة المحاولة ، وبدلاً من ذلك سيتم استخدام البيانات الموجودة في ذاكرة التخزين المؤقت كاستجابة. يتم تنفيذ ذلك في وظيفة optimisticFetchLink .

في رأيي ، يعد سلوك "الجلب المتفائل" هذا أحد أهم أجزاء برنامج Apollo-offline ، وأي تنفيذ مستقبلي لـ 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,
}

المشكلات المعروفة / الأجزاء المفقودة

• هذا يعمل فقط مع رد الفعل الأصلي في الوقت الحالي. يجب سحب الشيك isOnline لجعل هذا النظام متعدد المنصات.
• إذا كان لديك رد جزئي فقط في ذاكرة التخزين المؤقت ، فستتلقى وعدًا مرفوضًا في مكان ما أسفل السطر يخبرك أن الرد غير مكتمل. لم أفكر بعد في كيفية إصلاح ذلك ، أو في الواقع كيف يحل Apollo-Off هذا الأمر. إذا كنت تريد محاولة إصلاح هذا ، فسأكون ممتنًا لأي مؤشرات حول هذا الأمر.
• لا يمكنك حاليًا تغيير أي من إعدادات إعادة المحاولة - يجب إضافة هذا كمعامل تكوين إضافي.
• ليس لديك سيطرة على الجلب المتفائل. يجب أن تكون قادرًا على تعيين هذا بشكل مستقل لكل استعلام. لست من أشد المعجبين بتطبيق Apollo-Offline لهذا (إعداد متغير استعلام {__online_: true} ) ، ولكن يجب أن يكون هناك بالتأكيد طريقة ما للقيام بذلك.
• من الواضح أنه لا توجد اختبارات أيضًا.

سأكون ممتنًا لأي شخص يبحث عن حل لهذه التجربة ، ويمكننا بعد ذلك تحويل هذا إلى وحدة npm مناسبة مع الكتابة والاختبارات والمستندات والكثير. هذا السلوك مهم للغاية في رأيي ، ومن العار حقًا أن Apollo-client 2 ليس لديه حل مناسب لهذا حتى الآن.

واحد لطيف ✌️

@ smithaitufe ،

كيف يختلف هذا عن طابور الارتباط أبولو؟

يبدو أن apollo-link-queue يقوم بأشياء ذكية بناءً على حالة الاتصال. apollo-cache-persist يحفظ ذاكرة التخزين المؤقت ؛ السماح ، على سبيل المثال ، للمستخدمين ببدء تشغيل تطبيقك وتشغيله أثناء انقطاع الاتصال. بدون الاستمرار في ذاكرة التخزين المؤقت ، سيحتاج التطبيق إلى اتصال لبدء التشغيل ،

من المحتمل أن نرغب في كليهما ، أو الأفضل من ذلك ، حل lachenmayer أعلاه (الذي يستخدم قائمة انتظار ارتباط أبولو) وذاكرة تخزين مؤقت دائمة. (نحن نتحادث في مستودعات الارتباط ، لذا ينصب التركيز الأكبر هنا على ذلك)

lachenmayer من النظرات الأولى ، يبدو

أنا أتفق معك تمامًا بشأن ضرورة وجود شيء مثل ميزة الجلب المتفائلة لـ apollo-offline . كان (أو بالأحرى عدم وجوده) هو ما ألهمني إلى حد كبير لبدء apollo-offline .

أنا نفسي لست راضيًا تمامًا عن الطريقة التي اضطررت بها إلى التنفيذ الانتقائي لتمكين / تعطيل ميزة الجلب المتفائلة في apollo-offline . لم تكن متغيرات الاستعلام هي الخيار الأول ، لكنها بدت وكأنها الخيار الأكثر عملية. ماذا تقترح؟

الأسبوعان المقبلان سيكونان مرهقين للغاية بالنسبة لي. بعد ذلك ، سأكون أكثر من سعيد للمساهمة في تنفيذ حل أول حديث غير متصل بالإنترنت لـ Apollo - قد يكون هذا إصدارًا جديدًا من حزمة apollo-offline أو شيء مثل apollo-link-offline .

شكرا MLPXBrachmann!
أشعر أنه يجب التحكم في الجلب المتفائل باستخدام fetchPolicy - إذا كنت لا أريد أن يأتي أي شيء من ذاكرة التخزين المؤقت ، فيجب أن أتمكن من استخدام network-only .

تضمين التغريدة

أنا أكثر من مستعد وراغب في المساهمة.

أنا أيضًا أبحث عن خيارات لتنفيذ السلوك في وضع عدم الاتصال في تطبيق Apollo. يبدو النهج من lachenmayer واعدًا للغاية ، ولكن نظرًا لأنه يعتمد على apollo-link-retry ، فلن تستمر الطفرات التي لم يتم تطبيقها بنجاح ، لذلك إذا تم تحديث الصفحة ، فستكون أي بيانات لم يتم الالتزام بها للخادم تم تجاهلها (أفترض أن هذا هو الشيء نفسه في رد الفعل الأصلي إذا تم تعليق التطبيق). هل هناك أي عمل أو على الأقل مناقشة في هذا الجانب؟

nicocrm أرى ... في الوقت الحالي ، فإن المناقشة حول الدعم غير المتصل هي في الغالب في هذه القضية. أعتقد أن لدى Apollo أولويات أخرى في الوقت الحالي ، لذلك يجب علينا إنشاء مشروع مجتمعي apollo-link-offline . نأمل أن يؤدي هذا إلى مزيد من المناقشة والتقدم أكثر من الآن 😄

benseitz أنا بالتأكيد أؤيد ذلك. هناك الكثير من الاهتمام بالميزة ، لذلك أنا متأكد من وجود مساحة لمشروع مجتمعي - طالما أنني لا أقوم بتكرار أو تجزئة الجهد الحالي ، يمكنني إنشاء فريق جديد وإعادة الشراء لـ apollo-link-offline ودعوة جميع المهتمين . لدي بعض الاهتمام الشخصي بالإضافة إلى أحد العملاء الذين يدفعون حقًا من أجل هذه الميزة ، لذلك سيكون لدي بعض الساعات لأحترقها. سأطلب من الريبو غير المتصل أبولو لمعرفة ما إذا كانوا يريدون تولي زمام المبادرة لأن لديهم الكثير من الخبرة.

أنا بالتأكيد لدي اهتمام شخصي بهذا أيضًا - سأكون سعيدًا بمزيد من الدردشة معك على nicocrm هذا. لم ألاحظ أي طلبات مفقودة حتى الآن على رد الفعل الأصلي ولكن tbh لم أختبر كل هذه الأشياء بشكل صحيح (فقط مع الاستعلامات حتى الآن ويبدو أن تشغيل كل شيء على ما يرام).

أشعر أنه سيكون من المنطقي البدء في إعادة الشراء لهذا الغرض. ذكرMLPXBrachmann الذي apollo-offline أعلاه أنه لن يكون لديه الوقت الكافي لتحسين apollo-offline في الأسبوعين المقبلين ، وأعتقد أنه من المنطقي أن نطلق عليه apollo-link-offline .

لا أعتقد أن هناك أي كود يمكن إعادة استخدامه من apollo-offline لأنه خاص بإعادة الاستخدام.

nicocrm أنا أتفق معك كثيرًا. يجب أن تكون الاستفسارات / الطفرات المستمرة في قائمة الانتظار شيئًا محتملًا يعتني به apollo-link-offline .

benseitz أعتقد أيضًا أنها ستكون فكرة رائعة أن تبدأ apollo-link-offline كجهد مجتمعي وأرغب بشدة في المشاركة في تطويره.

lachenmayer أنت محق تمامًا ، مقدار الشفرة الذي تمت مشاركته بواسطة apollo-offline apollo-link-offline والحزمة المخطط لها

على أي حال ، سأكون سعيدًا لمناقشة أفكار apollo-link-offline ، وإعطاء ملاحظات حول التنفيذ - وبمجرد أن يتحرر الجدول الزمني الخاص بي قليلاً - ساهم ببعض التعليمات البرمجية أيضًا.

MLPXBrachmannlachenmayernicocrm هذه الأصوات مثل الطريقة الصحيحة للقيام بذلك!
حيث يمكن لأي شخص فتح قناة عامة على Apollo Slack . أود أن أقترح فتح ملف يسمى apollo-link-offline . ربما هذا يجعل التواصل بيننا أسهل قليلاً. يجب توثيق جميع القرارات المهمة في GitHub Issues.

هل أنت بخير معي بفتح كل من قناة الريبو والسلاك أم أن أحدكم يريد القيام بذلك؟

بالتأكيد شكرا لك!

أضفتك ثلاثة كمتعاونين إلى الريبو . ويمكنك الانضمام إلى قناة #apollo-link-offline في Apollo Slack

بالطبع الجميع مدعوون للتعاون في GitHub Repo والمناقشة على Slack :)
أنا متحمس جدا 💯

بالنسبة لأولئك الذين يصلون إلى هنا من بحث Google ، فقد كتبت ملخصًا لجميع التقنيات الحالية غير المتصلة بالإنترنت المتاحة اليوم لبرنامج Apollo Client 2.0.

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

هل يعمل Apollo على مكافئ AWS AppSync؟ لدينا بالفعل خادم GraphQL ونحتاج إلى تخزين مؤقت للعميل دون اتصال بالإنترنت للاستعلامات والطفرات باستخدام خادمنا ، وليس حلول AWS (مثل Lamda و DynamoDB و Elastic Search).

أتمنى أن تعمل.

masull سيكون ذلك مذهلاً تمامًا. لقد حاولت ولم أعتقد أن Firebase أو منصة التحليل تعمل من أجلي ، لذا فإن امتلاك هذه الميزة سيكون رائعًا.
تواجه صعوبة في إعداد كل شيء مع الكثير من الحزم ... ليس ممتعًا على الإطلاق :)