Дослідіть рух local-first програмного забезпечення — від CRDT до синхронізаційних рушіїв. Дізнайтеся, чому розробники обирають офлайн-першу архітектуру та як вона змінює застосунки для особистих фінансів.
Майже два десятиліття хмарні обчислення домінують у тому, як ми створюємо програмне забезпечення. Кожна презентація стартапу містила однакову архітектуру: тонкий клієнт, потужний сервер, дані в хмарі. Але відбувається дещо цікаве. Зростаюча спільнота розробників, дослідників та компаній ставить під сумнів цю ортодоксію і створює програмне забезпечення, що працює інакше. Вони називають це local-first програмне забезпечення.
Це не відмова від інтернету чи співпраці. Натомість це фундаментальне переосмислення того, де живуть дані, кому вони належать і як мають поводитися застосунки. Для розробників, які створюють персональне програмне забезпечення, особливо в чутливих сферах на кшталт фінансів, здоров'я та особистої продуктивності, архітектура local-first пропонує переконливі переваги, які хмарні підходи просто не здатні забезпечити.
Local-first програмне забезпечення — це підхід, за якого ваші дані переважно зберігаються на вашому пристрої, а не на віддаленому сервері. Застосунок працює офлайн за замовчуванням, розглядає локальну копію як джерело істини і синхронізується з іншими пристроями або користувачами, коли з'являється зв'язок.
Це відрізняється від традиційних підходів у важливих аспектах:
Хмарні застосунки зберігають ваші дані на віддалених серверах. Локальний пристрій є лише вікном перегляду даних, які знаходяться деінде. Коли ви офлайн, функціональність обмежена або відсутня. Прикладами є Google Docs, Notion та більшість SaaS-застосунків.
Застосунки з підтримкою офлайн можуть працювати без інтернету, але все одно вважають сервер канонічним джерелом даних. Ваші локальні зміни відкладаються, доки не зможуть бути відправлені на сервер. Прикладами є багато мобільних застосунків, які кешують дані для офлайн-перегляду.
Local-first застосунки перевертають цю модель. Ваш пристрій зберігає основну копію ваших даних. Ви можете працювати необмежено без мережевого доступу і без втрати функціональності. Синхронізація — це однорангова операція між пристроями, а не завантаження клієнт-сервер. Прикладами є Git, Obsidian та архітектура синхронізації Linear.
Ця відмінність має значення, тому що вона змінює фундаментальні припущення щодо власності, доступності та приватності.
У 2019 році дослідницька лабораторія Ink & Switch опублікувала статтю, яка кристалізувала бачення local-first. Їхнє есе «Local-First Software: You Own Your Data, in Spite of the Cloud» сформулювало сім ідеалів для local-first програмного забезпечення:
Цей маніфест знайшов глибокий відгук серед розробників, які були розчаровані обмеженнями та прив'язкою до хмарних сервісів. Він спровокував відновлений інтерес до технологій, що могли б зробити local-first програмне забезпечення практичним у масштабі.
Стаття Ink & Switch не винайшла ці ідеї. Дослідники розподілених систем працювали над основоположними проблемами десятиліттями. Але стаття перенесла академічні концепції в практичну розмову про розробку програмного забезпечення і дала руху цілісну ідентичність.
Створення local-first програмного забезпечення вимагає вирішення складних проблем розподілених систем. Коли кілька пристроїв можуть незалежно змінювати дані без координації, як об'єднати ці зміни без конфліктів? Як забезпечити, щоб усі зрештою бачили однаковий стан?
CRDT — це структури даних, спеціально розроблені для розподілених систем, де вузли можуть змінювати стан без координації. Ключова ідея полягає в тому, що якщо ретельно спроектувати структури даних, одночасні модифікації завжди можуть бути об'єднані автоматично без конфліктів.
Розглянемо простий приклад: лічильник. У традиційній системі, якщо два користувачі одночасно збільшують лічильник з 5 до 6, виникає конфлікт. Яке значення правильне?
CRDT-лічильник працює інакше. Замість зберігання одного числа він зберігає інкременти від кожного користувача окремо. Інкременти Користувача A відстежуються незалежно від Користувача B. Поточне значення обчислюється як сума всіх інкрементів. Якщо A збільшує один раз і B збільшує один раз, загальна сума дорівнює 7, незалежно від порядку отримання операцій. Жодного конфлікту, жодної координації.
Цей принцип поширюється на складніші структури даних:
Дослідницька спільнота CRDT розробила структури для різних випадків використання: карти, графи, JSON-документи та форматований текст. Бібліотеки на кшталт Yjs, Automerge та CRDTs надають готові до виробництва реалізації.
CRDT вирішують проблему вирішення конфліктів, але залишають відкритими питання про те, як зміни поширюються між пристроями. Синхронізаційні рушії обробляють цей рівень, керуючи:
Сучасні синхронізаційні рушії, такі як Replicache, PowerSync та Electric SQL, надають ці можливості як інфраструктуру, на якій застосунки можуть будуватися. Вони обробляють складність синхронізації стану, надаючи прості API для читання та запису даних.
Теорема CAP стверджує, що розподілена система може забезпечити максимум дві з трьох гарантій: узгодженість (Consistency), доступність (Availability) та стійкість до розділення (Partition tolerance). Оскільки мережеві розділення неминучі (ваш пристрій вимкнеться з мережі), практичні системи мають обирати між узгодженістю та доступністю.
Хмарні системи зазвичай обирають узгодженість. Коли ви офлайн, ви не можете вносити зміни, тому що система не може гарантувати, що ці зміни будуть узгоджені з тим, що роблять інші.
Local-first системи обирають доступність. Ви завжди можете працювати, навіть офлайн. Система використовує CRDT або подібні техніки, щоб забезпечити об'єднання всіх змін без конфліктів при відновленні зв'язку. Компромісом є кінцева узгодженість: різні пристрої можуть тимчасово бачити різні стани, збігаючись з часом.
Для більшості застосунків особистої продуктивності та фінансів цей компроміс є вигідним. Користувачі воліють працювати зараз і синхронізуватися пізніше, ніж бути заблокованими в очікуванні мережевого доступу.
Підхід local-first — це не лише теорія. Кілька успішних продуктів демонструють його життєздатність:
Linear — це інструмент управління проєктами, який досяг видатної продуктивності завдяки архітектурі local-first. Незважаючи на те, що це інструмент для командної роботи, Linear зберігає дані локально та синхронізує їх між пристроями. Результатом є застосунок, який відчувається миттєвим. Кожна дія реагує негайно, тому що вона спочатку відбувається локально.
Linear використовує власний синхронізаційний рушій для поширення змін. Коли ви створюєте завдання, воно існує локально миттєво і синхронізується із сервером та пристроями інших членів команди у фоновому режимі. Якщо ви офлайн, ви продовжуєте працювати. Зміни об'єднуються автоматично при повторному підключенні.
Співпраця в реальному часі у Figma працює на CRDT під капотом. Кілька дизайнерів можуть працювати над одним файлом одночасно, тому що модель даних Figma розроблена для одночасної модифікації. Зміни об'єднуються автоматично без конфліктів.
Хоча Figma переважно розміщується в хмарі, її базова технологія демонструє принципи CRDT у масштабі. Інженерна команда опублікувала численні матеріали про їхню багатокористувацьку архітектуру та CRDT-подібні структури, які вони використовують.
Obsidian — це застосунок для нотаток, який зберігає нотатки як звичайні Markdown-файли у вашій локальній файловій системі. Сервера немає. Ваші нотатки — це файли на вашому диску, які можна відкрити будь-яким текстовим редактором.
Для синхронізації Obsidian пропонує необов'язкові сервіси, або ви можете використовувати власне рішення для синхронізації (Dropbox, iCloud, Git, Syncthing). Цей підхід дає користувачам повну власність та гнучкість. Ваші нотатки не можуть бути заблоковані у пропрієтарному форматі, і вони збережуться незалежно від того, що станеться з Obsidian як компанією.
Excalidraw — це віртуальна дошка з відкритим вихідним кодом, яка працює повністю офлайн. Вона зберігає малюнки у локальному сховищі вашого браузера та може експортувати у файли. Спільна робота в реальному часі доступна, але необов'язкова. Основний функціонал малювання не потребує сервера взагалі.
Вбудовані застосунки продуктивності Apple використовують архітектуру local-first із синхронізацією через iCloud. Дані зберігаються на пристрої та синхронізуються через інфраструктуру Apple. Критично важливо, що застосунки повноцінно працюють офлайн, а зміни поширюються при відновленні зв'язку.
Рух local-first набирає обертів, тому що розробники усвідомлюють конкретні переваги:
Коли дані локальні, кожна операція швидка. Немає мережевої затримки між користувачем та його даними. Це створює застосунки, які якісно відрізняються від хмарних альтернатив.
Користувачі помічають різницю одразу. Застосунки відчуваються «швидкими» та «чуйними» у способи, які складно описати словами, але які одразу помітні. Це не оптимізація — це фундаментальна архітектурна перевага.
Хмарні застосунки ставляться до офлайну як до крайнього випадку, який потрібно терпіти. Local-first застосунки ставляться до офлайну як до основного сценарію використання. Різниця помітна у користувацькому досвіді.
З local-first немає «офлайн-режиму», який обмежує функціональність. Немає тривоги щодо того, чи будуть збережені зміни. Застосунок працює однаково, незалежно від того, чи ви в літаку, в підвалі, чи підключені до швидкого WiFi.
Коли дані живуть на пристроях користувачів, користувачі володіють своїми даними у повноцінному сенсі. Вони можуть створювати резервні копії, експортувати, перевіряти та переносити їх при зміні застосунку. Немає прив'язки до постачальника через утримання даних.
Ця власність поширюється на довговічність даних. Локальні файли даних залишатимуться читабельними десятиліттями. SaaS-сервіси регулярно закриваються, залишаючи користувачів у поспіху експортувати дані, поки вони не зникли.
Local-first програмне забезпечення є приватним за своєю конструкцією. Якщо дані не залишають пристрій, вони не можуть бути витікані з сервера. Немає сервера для злому, немає бази даних для хакерської атаки, немає доступу працівників для зловживання.
Це приватність не через політику, а приватність через архітектуру. Користувачам не потрібно довіряти практикам конфіденційності компанії, тому що архітектура робить порушення приватності технічно неможливими.
Запуск хмарного застосунку потребує серверів, баз даних та постійних операційних витрат, що масштабуються з кількістю користувачів. Local-first застосунки перекладають обчислення та зберігання на пристрої користувачів. Граничні витрати на додаткового користувача наближаються до нуля.
Для незалежних розробників та невеликих команд це змінює економіку розробки програмного забезпечення. Ви можете створювати стійке програмне забезпечення без венчурного капіталу для фінансування серверної інфраструктури.
Незважаючи на складність концепцій розподілених систем, local-first розробка може бути простішою за хмарну. Ви створюєте застосунок, що працює на одному пристрої спочатку. Потім додаєте синхронізацію зверху. Основна логіка — це пряма розробка застосунку без складності розподілених систем.
Сучасні синхронізаційні рушії абстрагують більшість складності розподілених систем. Розробники працюють зі знайомими API, поки інфраструктура обробляє вирішення конфліктів та поширення стану.
Особисті фінанси — це ідеальна сфера для архітектури local-first. Вимоги ідеально збігаються із сильними сторонами local-first:
Фінансові дані є одними з найчутливіших даних, якими володіють люди. Історії транзакцій розкривають, де ви здійснюєте покупки, що купуєте, кому платите та скільки заробляєте. Ці дані у чужих руках дозволяють крадіжку ідентичності, переслідування, дискримінацію та маніпулювання.
Хмарні фінансові застосунки є привабливими цілями для зловмисників. Централізовані бази даних з фінансовими історіями мільйонів користувачів — це високоцінні цілі. Зломи не є гіпотетичними — вони трапляються регулярно.
Архітектура local-first повністю усуває цю категорію ризиків. Немає централізованої бази даних для злому, тому що дані залишаються на пристроях користувачів.
Люди потребують доступу до своїх фінансових даних за будь-яких обставин: подорожуючи за кордон, у районах з поганим зв'язком, під час збоїв сервісу. Бюджетний застосунок, який не працює офлайн, недостатньо надійний для основного фінансового інструменту.
Local-first фінансові застосунки працюють будь-де та будь-коли. Ваші фінансові дані на вашому пристрої, доступні незалежно від мережевих умов.
Управління фінансами є за своєю суттю особистим. На відміну від спільних документів чи командних проєктів, більшість людей не потребує ділитися відстеженням витрат з іншими в реальному часі. Оптимізація для одного користувача у local-first — це перевага, а не обмеження.
Це також спрощує реалізацію. Без вимог до співпраці в реальному часі рівень синхронізації може зосередитися на синхронізації пристрій-пристрій для того самого користувача, а не на вирішенні багатокористувацьких конфліктів.
Люди відстежують фінанси роками або десятиліттями. Вам потрібно, щоб ваші дані були доступні у 2030 році та далі. Чи існуватиме той хмарний сервіс? Чи зміниться їхнє ціноутворення? Чи будуть вони придбані та закриті?
Local-first дані існують незалежно від будь-якої компанії. Звичайні файли даних на вашому пристрої залишатимуться читабельними, доки ви підтримуєте резервні копії.
Для користувачів у певних юрисдикціях або професіях зберігання фінансових даних у третіх осіб порушує питання комплаєнсу. Архітектура local-first спрощує дотримання нормативних вимог, зберігаючи дані під контролем користувача.
Budgie побудований з нуля як local-first застосунок для особистих фінансів. Ось як ми реалізуємо ідеали local-first:
Усі ваші фінансові дані, включаючи транзакції, рахунки, бюджети та категорії, зберігаються в локальній базі даних SQLite на вашому пристрої. Ми використовуємо Drizzle ORM для типобезпечних операцій з базою даних, забезпечуючи цілісність даних, зберігаючи все локально.
Немає сервера Budgie, який зберігає ваші фінансові дані. Ми не маємо доступу до ваших транзакцій, тому що ми їх ніколи не отримуємо.
Оскільки дані локальні, кожна взаємодія миттєва. Додавання транзакції, категоризація витрат, перегляд звітів — все це відбувається на швидкості локального доступу. Немає індикаторів завантаження в очікуванні мережевих відповідей.
Це особливо помітно у ресурсомістких операціях, таких як генерація звітів або пошук в історії транзакцій. Операції, які потребували б дорогих запитів до бази даних у хмарній архітектурі, виконуються миттєво на пристрої.
Budgie працює повністю офлайн. Ви можете відстежувати витрати в літаку, переглядати бюджет у віддаленій хатинці або управляти фінансами в районах без мобільного покриття. Кожна функція працює без мережевого доступу.
Коли у вас є підключення, Budgie може опціонально синхронізуватися з вашим банком для автоматичного імпорту транзакцій. Але це доповнення, яке покращує local-first основу, а не вимагає її.
Для користувачів, які хочуть автоматичний імпорт транзакцій, Budgie пропонує банківську синхронізацію з архітектурою нульового знання. Ваші банківські облікові дані зашифровані локально на вашому пристрої. Операції синхронізації відбуваються безпосередньо між вашим пристроєм та вашим банком. Інфраструктура Budgie ніколи не бачить ваших облікових даних чи даних транзакцій.
Це дає вам зручність автоматичного імпорту без жертвування гарантіями приватності архітектури local-first. Ви можете дізнатися більше про наш підхід до безпеки у [розділі безпеки](/#security).
Кодова база Budgie є відкритою, що дозволяє дослідникам безпеки та допитливим користувачам перевіряти наші заяви. Ви можете точно перевірити, як зберігаються дані, підтвердити, що нічого не передається на наші сервери, і навіть зібрати застосунок самостійно.
Відкритий вихідний код також вирішує питання довговічності. Навіть якщо Budgie як компанія зникне, код залишається доступним. Спільноти можуть підтримувати та розширювати його необмежено.
Ваші дані — це ваші дані. Budgie підтримує експорт ваших фінансових даних у стандартних форматах. Якщо ви коли-небудь захочете перейти на інший застосунок або проаналізувати дані в електронній таблиці, у вас є повний доступ.
Ми віримо в те, що потрібно заслуговувати на ваше продовження використання через якість, а не утримувати вас через прив'язку до даних.
Для розробників, зацікавлених у створенні local-first застосунків, ось практичні відправні точки:
Кілька готових до виробництва бібліотек надають інфраструктуру local-first:
Yjs — це реалізація CRDT, орієнтована на спільне редагування тексту. Вона працює в кількох спільних редакторах і має зрілу екосистему.
Automerge — це JSON CRDT реалізація, яка спрощує роботу зі складними структурами документів. Вона особливо сильна для застосунків, яким потрібно синхронізувати довільні JSON-дані.
Replicache надає синхронізаційний рушій, який працює з вашим існуючим бекендом. Він обробляє складність офлайн-першої синхронізації, дозволяючи зберегти існуючу серверну архітектуру.
PowerSync пропонує синхронізацію в реальному часі для мобільних та веб-застосунків з Postgres бекендами.
Electric SQL синхронізує бази даних SQLite між пристроями та хмарним Postgres, забезпечуючи local-first зі знайомим SQL.
Почніть з одноприладного застосунку та додайте синхронізацію пізніше. Спочатку правильно налаштуйте модель даних для локального зберігання. Зрозумійте, який стан потрібен вашому застосунку та як він змінюється.
Потім нашаруйте синхронізацію зверху. Сучасні синхронізаційні рушії роблять цей поступовий підхід практичним. Вам не потрібно проєктувати для розподілених систем з першого дня.
Ментальні моделі мають значення. У local-first застосунку різні пристрої можуть тимчасово бачити різні стани. Проєктуйте свій інтерфейс так, щоб він елегантно обробляв цю ситуацію.
На практиці для більшості персональних застосунків це рідко помітно користувачам. Синхронізація достатньо швидка, щоб вікна неузгодженості були короткими. Але ваш код не повинен припускати миттєву узгодженість.
Подумайте про такі сценарії: що якщо користувач вносить суперечливі зміни на двох пристроях перед синхронізацією? Що якщо синхронізація перерветься на половині? Що якщо пристрій перебуває офлайн тривалий час?
CRDT обробляють це автоматично для об'єднання даних. Але логіка вашого застосунку також може потребувати обробки цих випадків. Бюджетний застосунок має поводитися розумно, якщо та сама транзакція введена на двох пристроях.
Рух local-first прискорюється. Кілька тенденцій свідчать про те, що це не нішевий інтерес, а фундаментальний зсув:
Маятник хитається від максимальної централізації до більш збалансованої архітектури, де локальні та хмарні обчислення виконують те, що кожне з них робить найкраще.
Ці терміни часто використовуються як взаємозамінні, але є відмінність. Offline-first зазвичай означає застосунок, який кешує дані для офлайн-доступу, але все одно вважає сервер авторитетним. Local-first йде далі: локальний пристрій є джерелом істини, а сервер (якщо присутній) — це лише ще один пір для синхронізації. Local-first передбачає справжню власність на дані, а не лише офлайн-кешування.
Так. CRDT були спеціально розроблені для забезпечення співпраці в реальному часі без центральної координації. Застосунки на кшталт Figma та Linear демонструють, що архітектура local-first може підтримувати складні функції співпраці. Ключова відмінність полягає в тому, що співпраця відбувається через однорангову синхронізацію, а не через центральний сервер.
Користувачі контролюють власну стратегію резервного копіювання. Це може включати локальні резервні копії пристрою (iCloud, Google backup), ручний експорт або синхронізацію з сервісом за вибором користувача. Деякі local-first застосунки пропонують необов'язкові хмарні сервіси резервного копіювання для зручності, але вони є доповненням, а не обов'язковою вимогою. Ваші дані залишаються доступними через локальні резервні копії, навіть якщо будь-який хмарний сервіс зникне.
Спочатку є додаткова складність у розумінні CRDT та синхронізації. Однак local-first може бути дешевшим загалом, тому що вам не потрібно будувати та підтримувати серверну інфраструктуру у масштабі. Для незалежних розробників та невеликих команд зменшені операційні витрати можуть переважити початкову криву навчання. Сучасні бібліотеки та фреймворки також значно зменшують складність реалізації.
Деякі застосунки справді потребують серверних можливостей, таких як відправка електронних листів або обробка платежів. Local-first — це про те, де живуть дані та кому вони належать, а не про повне усунення серверів. Local-first застосунок може використовувати сервери для конкретних можливостей, зберігаючи дані користувача локально. Ключове — сервер обробляє дії, а не зберігає особисті дані.
Local-first застосунки мають фундаментально кращу позицію безпеки: немає централізованої бази даних з даними користувачів для злому. Питання безпеки зміщуються до безпеки пристрою, яку користувачі контролюють через паролі пристрою, біометрію та шифрування. Для чутливих даних, таких як фінансова інформація, це зазвичай є значним чистим покращенням безпеки.
Рух local-first являє собою справжню еволюцію в тому, як ми думаємо про архітектуру програмного забезпечення. Для розробників, які створюють персональні інструменти, програмне забезпечення для продуктивності або застосунки в чутливих сферах на кшталт фінансів та здоров'я, local-first пропонує шлях до кращої продуктивності, сильнішої приватності та справжньої власності користувачів.
Budgie — це наш внесок у це майбутнє: застосунок для особистих фінансів, який зберігає ваші фінансові дані там, де їм належить бути — на вашому пристрої під вашим контролем.
Готові відчути local-first особисті фінанси? [Приєднуйтесь до списку очікування](/#waitlist), щоб бути серед перших, хто спробує Budgie.
2025-02-10
Технічний огляд офлайн-першої архітектури Budgie: як SQLite, шифрування AES-256 та синхронізація між пристроями забезпечують повну конфіденційність ваших фінансових даних.
Читати статтю→2025-11-06
Дізнайтеся, чому офлайн-орієнтована архітектура є єдиним справді приватним підходом для фінансових додатків. Дізнайтеся про ризики даних, конфіденційність за замовчуванням та як Budgie захищає ваші фінанси.
Читати статтю→Приєднайтеся до списку очікування Budgie та станьте першими, хто відчує справді приватний облік витрат.
Приєднатися до списку очікування