Персональные веб-приложения

Дата публикации: 2024-03-24

До веба приложения обычно хранили данные на компьютере владельца. С распространением веба данные переехали на корпоративные серверы, а приватности стало меньше. Что изменится, если личные данные веб-приложения будут прежде всего храниться на телефоне или компьютере самого пользователя?

Чем веб-приложение отличается от нативного

Главные отличия просты: веб-приложение работает в браузере, а для его доставки обычно нужен сервер. Браузер стал своего рода операционной системой для таких программ: у него есть Web API, правила безопасности и доступ к экрану, клавиатуре, мыши, камере и другим возможностям устройства. Этот доступ ограничен сильнее, чем у нативной ОС, но его достаточно для взаимодействия человека, устройства и других программ.

Когда-то программы приносили на дискетах и CD, теперь почти всё приходит по сети. Но браузерные ограничения пока не позволяют полноценно запускать веб-приложение просто с флешки: нужен безопасный origin, откуда браузер получит код.

В привычной схеме и код, и основные данные пользователей находятся на сервере.

Личное хранилище

Современные браузеры умеют сохранять и обрабатывать значительные объёмы данных на клиенте через IndexedDB. Лимиты зависят от устройства и браузера и могут измеряться десятками гигабайт. Поэтому личную информацию приложения можно хранить непосредственно на устройстве владельца.

Часть данных, например для начальной аутентификации, всё ещё может быть на сервере. Но перенос основной личной обработки на устройство снижает требования к центральной инфраструктуре и уменьшает объём информации, который она видит.

Роль сервера

Сервер всё равно раздаёт код приложения и помогает передавать данные между людьми. Если получатель онлайн, сообщение можно доставить сразу. Если офлайн — сервер временно буферизует зашифрованное сообщение до следующего подключения. Это похоже на раннюю почту по POP3, где сервер держал письма до получения клиентом.

WebRTC

Когда оба участника онлайн, WebRTC может передать данные напрямую; сервер нужен лишь для первоначального согласования соединения. Нагрузка тогда распределяется между парами пользователей, а не проходит через один центральный узел.

При асимметричном шифровании участники обмениваются публичными ключами, шифруют и проверяют сообщения. Сервер может пересылать зашифрованный буфер офлайн-получателю, не имея ключей к содержимому. На практике нужны также защита ключей, проверка личности, резервное копирование и продуманное восстановление доступа.

Облака и pods

У одного человека часто несколько устройств с одним приложением. Если каждое держит собственную базу, необходима репликация — личное облако или pod, через который синхронизируются данные ноутбука и телефона.

Эту роль уже играют Dropbox, Google Drive, OneDrive и подходы вроде Solid. Даже для одного устройства внешнее хранилище полезно как резервная копия на случай потери телефона или компьютера.

Вывод

Персональное веб-приложение не отказывается от сервера: оно меняет распределение ответственности. Устройство пользователя держит и обрабатывает личные данные, сервер доставляет код и координирует обмен, а выбранное владельцем хранилище синхронизирует и резервирует данные. Такая архитектура перспективна, если вместе с приватностью проектируются надёжная синхронизация, шифрование и восстановление данных.

Личное хранилище, профиль и связь нескольких устройств — одна из граней более общей модели браузера как персональной среды. Она собрана в книге «Браузер как операционная система для разработки современных приложений».