Local-First English: ElectricSQL and Sync Architecture (англійською)

Вивчіть англійську лексику архітектури local- first і ElectricSQL — пояснення CRDT, стану синхронізації, розв’ язання конфліктів, форм даних і затримки реплікації.

Introduction

** Local- first ** — це філософія архітектури програмного забезпечення, за якої дані зберігаються на пристрої користувача, а сервер використовується для синхронізації, а не як головне сховище даних. ** ElectricSQL ** — один з інструментів, який робить це практичним для програм, що працюють на PostgreSQL. Цей підхід вводить словник, який не схожий на що-небудь в традиційному клієнт-серверному розвитку — такі терміни як CRDT, кінцева послідовність і слот реплікації походять з досліджень розподілених систем, але зараз входять в основному веб-розробку. Ця стаття навчить вас розуміти і вільно використовувати цей словник.

Поняття локальної і локально-первинної здатності

** Можливість роботи поза мережею ** означає, що програму можна читати і записувати до неї навіть у відсутність з’ єднання з інтернетом. Коли з’єднання повертається, зміни синхронізуються автоматично. “Ми додали можливості автономного режиму до програми польової перевірки, щоб інженери могли записувати результати навіть в областях без сигналу.”

Ширший принцип проектування є offline-first - проектування програми для роботи в автономному режимі як типовий випадок, розглядаючи доступ до мережі як поліпшення, а не вимогу. *“Будування в автономному режимі означає, що ви повинні думати про розв’язання конфліктів з самого початку проекту, а не як про подальшу думку.” *

** Оптимістичне оновлення ** — це оновлення, у якому інтерфейс користувача негайно показує результат дії користувача до того, як сервер підтвердить її. Припускаємо, що операція буде успішною. * « За оптимістичних оновлень, натискання кнопки « подобається » відчувається миттєво — лічильник негайно збільшується, а синхронізація наздоганяє у фоні. » * Якщо синхронізація пізніше повідомить про конфлікт, інтерфейс користувача має примирити різницю.

Синхронізувати стан і форми даних

** Стан синхронізації ** описує поточний стан синхронізації між локальною базою даних і сервером. Клієнт може бути * повністю синхронізований *, * синхронізується *, * відстає * або * не на зв’ язку *. * « Показувати стан синхронізації у інтерфейсі користувача, щоб користувачі знали, чи були їхні останні зміни передані на сервер ». *

** data shape ** (або ** shape subscription ** у ElectricSQL) — це декларація того, який саме підмножина даних клієнт бажає отримати. Замість синхронізації всієї таблиці, ви підписуєтеся на форму, наприклад, лише на рядки, що належать поточному користувачеві. * « Визначте вузьку форму даних для мобільного клієнта, щоб програма не звантажувала всю таблицю замовлень — лише замовлення за останні 30 днів. » *

** Затримка реплікації ** — це затримка між записом зміни на одному вузлі (зазвичай, сервері) і її появою на іншому вузлі (зазвичай, клієнті). * « Під час наших тестів затримка реплікації була менше 200 мілісекунд за хорошого з’ єднання, але могла досягати декількох секунд за повільної мобільної мережі. » *

Слот реплікації є серверним механізмом в PostgreSQL, який відстежує, наскільки далеко абонент (наприклад, ElectricSQL) використовує журнал змін бази даних. “Якщо слот реплікації занадто відстає, PostgreSQL може заблокувати вилучення старих файлів WAL, що викликає проблеми з дисковим простором.”

Розв’язання конфліктів і CRDTs

** Розв’ язання конфліктів ** — це процес вирішення того, що робити, коли однакові дані змінюються у двох місцях одночасно — на пристрої, коли він не підключений до мережі, і на сервері. * « Наша стратегія розв’ язання конфліктів використовує правило « останній запис — перемагає » для простих текстових полів, але CRDT для спільних лічильників. » *

** CRDT ** — Conflict- Free Replicated Data Type — це структура даних, розроблена таким чином, що одночасні зміни з декількох джерел завжди можна об’ єднати автоматично без конфліктів. Поширені приклади включають лічильники, набори і спільні текстові документи. * “Ми обрали CRDT для спільного списку завдань, щоб два користувачі, які додають елементи в один час, ніколи не викликали конфлікт.” *

** Послідовність у випадку ** означає, що всі репліки (копії) даних зближаться до одного стану за достатньо тривалий час, навіть якщо вони тимчасово не збігаються. Це слабша гарантія, ніж сильна послідовність, але вона дозволяє працювати автономно. “Відповідність є прийнятною для спільного застосування записів, але ви не використовували б її для банківського балансу.”

Протокол синхронізації є набором правил, що регулюють, як зміни переміщуються між клієнтом і сервером — який формат використовувати, як замовляти оновлення, як обробляти конфлікти. “Протокол синхронізації ElectricSQL побудований на вершині логічної реплікації PostgreSQL, тому він успадковує її гарантії надійності.”

Ключовий словник

TermDefinition
offline capabilityThe ability to read and write data without an internet connection
optimistic updateShowing the result of an action in the UI before the server confirms it
sync stateThe current status of synchronisation between local and remote data
data shapeA declared subset of data that a client subscribes to receive
replication lagThe delay between a change being written and appearing on all replicas
CRDTA data structure that can be merged from concurrent changes without conflicts
eventual consistencyA guarantee that all replicas will converge to the same state over time
conflict resolutionThe strategy for reconciling data that was changed in multiple places simultaneously

Практичні поради

  1. ** Використовуйте « sync » як іменник, так і дієслово. ** У англійській мові ми говоримо * « the sync failed » * (іменник) і * « the app will sync when online » * (дієслово). Обидва способи використання є природними. Ви також можете сказати * « to sync » * (більш формально) або * « to sync » * (повсякденна технічна мова).

  2. ** Поясніть можливу послідовність за допомогою аналогії. ** Корисною аналогією англійською мовою є: * « Можлива послідовність схожа на дві людини, які редагують спільний документ поза мережею — вони можуть мати різні версії документа протягом певного часу, але коли вони знову під’ єднаються, зміни буде об’ єднано ». * Практикування пояснень у такий спосіб розвиває словниковий запас і навички спілкування.

  3. ** Вивчайте слово « lag » у технічному контексті. ** У повсякденній англійській мові слово « lag » означає затримку. У розподілених системах, «затримка реплікації» і «затримка синхронізації» описують затримки між вузлами. Також поширені: «мережеве затримання» і «вхідне затримання» в іграх. Зауважте, як слово поєднується з різними іменниками.

  4. ** Вправлятися у правильному використанні « subscribe ». ** У архітектурі « local- first » клієнти * підписуються на * форми даних. Передлога — це « to ». * « Клієнт підписується на форму, яка містить лише завдання поточного проекту. » * Це той самий передлог, що і у * « підписатися на новинну листівку. » *

Conclusion

Архітектура Local-first та інструменти, такі як ElectricSQL, представляють собою значний зсув у тому, як ми думаємо про дані, з’єднання та досвід користувача. Словник — CRDTs, кінцева послідовність, форми даних, стан синхронізації, розв’ язання конфліктів — відображає глибокі ідеї з досліджень розподілених систем, які зараз застосовуються до повсякденних застосунків. Знання і вміння правильно користуватися цією мовою допоможе вам брати участь у технічних обговореннях, писати чіткі документи щодо архітектури і ставити правильні питання під час оцінки того, чи є локальна версія правильним вибором для вашого проекту.

Національний склад населення: Перепис населення та житлово-комунальні послуги 2001 року

Основні концепції ElectricSQL - CRDT, синхронізація стану, розв’язання конфліктів - є потужними, але перетворення їх в ефективне спілкування в команді розробників може бути складним. Це не просто знання, що ви маєте справу з можливою послідовністю; це про вираження цього розуміння чітко і чітко колегам. Це особливо важливо для розробників, чия основна мова не є англійською, оскільки тонкі нюанси фразування навколо синхронізації даних є критичним. Давайте розглянемо кілька практичних сценаріїв, де ці концепції грають у реальних розмовах.

Розглянемо наступний випадок: ви переглядаєте запит на звантаження, який вводить нову функціональність, залежну від реплікації змін з віддаленої бази даних. Ваш колега описав свій підхід у описі PR як « обробка стану синхронізації ». Хоча це технічно вірно, його можна розглядати як просто опис того, як вони * виконують * синхронізацію. Точнішим і професійним формулюванням буде: «Я реалізував CRDT, щоб забезпечити послідовність даних між пристроями, вирішуючи потенційні проблеми з розв’ язанням конфліктів, що виникають через затримку реплікації». Це негайно повідомляє глибше розуміння основної технології і підкреслює проактивні кроки, вжиті для зменшення ризиків. Вона також запрошує до подальшого обговорення конкретних сценаріїв конфлікту - “Чи можете ви розібратися, як ви працюєте з розбіжними оновленнями в цій конкретній області?” є набагато продуктивнішим, ніж “Чи ви працюєте з станом синхронізації?”

Інша поширена ситуація включає обговорення затримки реплікації з колегою. Просте повідомлення Slack, наприклад, «Щойно розгорнуто оновлення; синхронізація даних» не достатньо для передачі потенційних наслідків. Замість цього, ви можете сказати: «Ми налаштували ElectricSQL так, щоб терпіти до 5 секунд затримки реплікації, але я уважно стежу за затримкою. Ми повинні переконатися, що будь-яке значне збільшення затримки не впливає на досвід користувача. “Це демонструє обізнаність про ключову метрику і підкреслює важливість проактивного моніторингу. Вона також встановлює очікування щодо прийнятної поведінки - “До 5 секунд” є набагато більш інформаційним, ніж просто заявляючи, що синхронізація відбувається.

Нарешті, при обговоренні форм даних в команді, важливо вийти за рамки простого згадування «цілісності даних». Формування його як «Ми визначаємо чіткі форми даних для кожної сутності - забезпечуючи послідовну схему у всіх репліках - зменшить конфлікти під час реплікації і поліпшить нашу здатність міркувати про зміни стану», демонструє більш складне розуміння архітектури.

Ось приклад того, як ви можете розпочати розмову щодо налаштування початкових параметрів синхронізації у ElectricSQL:

# Setting initial sync parameters for user profiles (CRDT example)
electric sql set --sync-initial-state --key-version "user_profile_v1" --conflict-resolution "merge" --replication-lag-threshold 3

Ця команда, якщо її пояснити чітко, показує свідомо обдуманий підхід до обробки початкової синхронізації даних.

Поширені запитання

Про що ця стаття "Local-First English: ElectricSQL and Sync Architecture (англійською)"?

Вивчіть англійську лексику архітектури local- first і ElectricSQL — пояснення CRDT, стану синхронізації, розв’ язання конфліктів, форм даних і затримки реплікації.

Чи безкоштовна ця стаття?

Так. Усі статті на CoderSlingo, включно з цією, доступні безкоштовно без реєстрації.

Скільки часу займає читання "Local-First English: ElectricSQL and Sync Architecture (англійською)"?

Приблизно 7 min.