Как построить браузерную ОС без сервера: разбор local-first архитектуры

Представьте веб-приложение, которое не отправляет данные на сервер, не требует аккаунта и работает даже при потере соединения. Большинство современных сайтов устроены наоборот: тяжёлый бэкенд, облачные базы, подписка. А что, если весь «сервер» — это браузер пользователя?

Именно этот вопрос себе задал автор проекта Cordoval — браузерной ОС, которая живёт в одной вкладке и обходится без серверной инфраструктуры. Расходы на хостинг — ноль. Задержки при обращении к базе — ноль. Телеметрия — отсутствует. При этом внутри есть рабочий стол, экономический симулятор и подкаст-плеер. Разберём, как это устроено и что стоит взять на заметку, если вы строите своё приложение без бэкенда.

Три кита local-first архитектуры

Вместо удалённой базы данные лежат на диске пользователя. Для этого используются два браузерных API.

OPFS и IndexedDB

Origin Private File System (OPFS) — это быстрый доступ к файлам прямо из браузера. В Cordoval он отвечает за бинарные файлы, тяжёлые документы и снапшоты состояния. IndexedDB, в свою очередь, хранит ключ-значение состояния приложения, настройки пользователя и индексы.

Почему это важно: нулевая задержка при чтении, полный офлайн и суверенность данных. Если сеть падает — ОС продолжает работать. Это резко контрастирует с классическими веб-сервисами, где потеря соединения означает «попробуйте позже».

Web Workers для тяжёлых вычислений

Экономический симулятор в Cordoval считает цены акций, облигации и недвижимость в реальном времени. Чтобы UI не тормозил, все вычисления вынесены в Web Workers — отдельные потоки, которые не блокируют интерфейс. Главный поток получает только готовые результаты через postMessage. В итоге рендеринг остаётся плавным, даже если внутри идёт сложная симуляция.

Нативный стриминг аудио

Подкаст-плеер внутри ОС работает без прокси-сервера для медиа. RSS-фид парсится прямо на клиенте через fetch(), а аудио стримится через HTML5 Audio. Никаких промежуточных серверов — только ваш браузер и оригинальный источник.

Монетизация без бэкенда: эксперимент Sharewall

У приложения нет аккаунтов и серверной аналитики. Поэтому классическая платная подписка тут не работает. Вместо этого автор придумал локальный «социальный замок».

• Приложение считает активные минуты через Page Visibility API — только когда вкладка реально на экране.
• После 30 активных минут доступ приостанавливается.
• Чтобы продолжить, нужно поделиться ссылкой через нативный navigator.share().
• После шаринга в localStorage пишется метка, которая открывает доступ на 30 дней.

Технически это можно обойти, открыв DevTools и подправив данные. Но для обычных пользователей это простой вирусный цикл без сбора данных. Идея интересная: монетизация внимания вместо подписки, и она не требует ни одного запроса на сервер.

Сравнение с классической архитектурой

Подводные камни, о которых нужно знать

Архитектура без бэкенда — не серебряная пуля. Источник честно перечисляет две главные проблемы.

Первая — мобильные браузеры. iOS Safari может вытеснить данные IndexedDB и PWA-хранилища, если приложение не добавлено на главный экран и им долго не пользовались. Поэтому обязателен механизм экспорта и импорта резервных копий. Иначе пользователь может потерять всё.

Вторая — CORS. Некоторые подкаст-хосты запрещают кросс-доменные запросы к своим RSS-фидам через строгие CDN-заголовки. Приходится аккуратно разруливать fallback на стороне клиента. Это ограничение не обойти чисто «локально».

Что делать, если вы хотите построить подобное

Из этого проекта можно вынести несколько практических принципов. Не как готовый рецепт, а как отправную точку.

1. Начните с IndexedDB для простых данных. Он есть во всех браузерах и прощает много ошибок.
2. Для больших бинарных данных переходите на OPFS — он заметно быстрее, но требует аккуратной работы с файловыми дескрипторами.
3. Выносите любые циклы и вычисления в Web Workers. Даже простая симуляция может подвесить интерфейс, если оставить её в главном потоке.
4. Не надейтесь, что браузер сохранит данные навсегда. Делайте экспорт в файл и напоминайте пользователю о резервной копии.
5. Если используете внешние данные (ленты, API), продумайте CORS-фолбэки. Возможно, часть запросов придётся тонко настраивать.

И отдельно про монетизацию: она возможна и без бэкенда. Конечно, sharewall с локальным токеном — это не защита от опытного хакера. Но для аудитории, которая не лезет в DevTools, это полностью рабочая схема, не требующая инфраструктуры.

Local-first подход меняет правила игры: сервер из точки отказа превращается в необязательный элемент. Пользователь получает контроль над данными, разработчик — нулевые расходы на хостинг. Разумеется, в таком подходе есть ограничения — от вытеснения хранилища браузером до CORS. Но для приложений, где приватность и офлайн важнее «серверной магии», это очень перспективный путь.