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, тому він успадковує її гарантії надійності.”
Ключовий словник
| Term | Definition |
|---|---|
| offline capability | The ability to read and write data without an internet connection |
| optimistic update | Showing the result of an action in the UI before the server confirms it |
| sync state | The current status of synchronisation between local and remote data |
| data shape | A declared subset of data that a client subscribes to receive |
| replication lag | The delay between a change being written and appearing on all replicas |
| CRDT | A data structure that can be merged from concurrent changes without conflicts |
| eventual consistency | A guarantee that all replicas will converge to the same state over time |
| conflict resolution | The strategy for reconciling data that was changed in multiple places simultaneously |
Практичні поради
-
** Використовуйте « sync » як іменник, так і дієслово. ** У англійській мові ми говоримо * « the sync failed » * (іменник) і * « the app will sync when online » * (дієслово). Обидва способи використання є природними. Ви також можете сказати * « to sync » * (більш формально) або * « to sync » * (повсякденна технічна мова).
-
** Поясніть можливу послідовність за допомогою аналогії. ** Корисною аналогією англійською мовою є: * « Можлива послідовність схожа на дві людини, які редагують спільний документ поза мережею — вони можуть мати різні версії документа протягом певного часу, але коли вони знову під’ єднаються, зміни буде об’ єднано ». * Практикування пояснень у такий спосіб розвиває словниковий запас і навички спілкування.
-
** Вивчайте слово « lag » у технічному контексті. ** У повсякденній англійській мові слово « lag » означає затримку. У розподілених системах, «затримка реплікації» і «затримка синхронізації» описують затримки між вузлами. Також поширені: «мережеве затримання» і «вхідне затримання» в іграх. Зауважте, як слово поєднується з різними іменниками.
-
** Вправлятися у правильному використанні « 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
Ця команда, якщо її пояснити чітко, показує свідомо обдуманий підхід до обробки початкової синхронізації даних.