Современные веб-приложения работают так. Есть апишка на сервере, которая возвращает данные в JSON. Бекенд ничего не знает о рендере, а только раздает данные и обрабатывает команды. И есть js-приложение на клиенте, которое забирает данные с бека и рендерит их. Все это понятно, и все так делают – но не думают вот о чем.

У бекенда, как бы криво он ни был написан, есть прочный фундамент – реляционная база данных. Она не пропустит откровенную дичь, сделает проверки на уникальность и целостность, словом, снимает ряд проблем. Кроме того, я могу окинуть всю базу взглядом: схему, зависимости, всякие вьюхи, функции и так далее. Тулинга под реляционные базы столько, что не знаешь, что выбрать.

Реляционная база, пусть даже это Sqlite, воздвигает столь мощный барьер от дурака, что не ценить его означает быть полным болваном. Да, иные ребята берут Монгу и прочие базы без схемы, но это путь в никуда. Рано или поздно проект придется мигрировать на Постгрес, либо стартап сожжет инвестиции и закроется.

Ключевая беда фронтенда в том, что там нет базы данных. Есть ублюдочные LocalStore и IndexedDB, которые по недоразумению называют базами данных. Да, в IndexedDB можно создать индекс btree по произвольному полю. Но в целом эти два ничто иное, как KV-хранилища. А судьба любого KV-хранилища одна – быть помойкой.

Дело в том, что KV не предполагает схемы. В коде нет никакой информации о том, что лежит в словаре. Вижу, что одно событие вынимает словарь, а другое пишет словарь. Что в них – неизвестно.

Сейчас работаю над сложным веб-приложением (UI-частью). Ему около семи лет, сменилось много разработчиков. И все подтверждает мой тезис – для работы с данными KV не годится абсолютно, совершенно. База данных приложения – огромный словарь, сущая помойка. Одни и те же данные читаются с бека и пишутся под разными ключами. Визуализатор базы – студенческая поделка: тысячи ключей не помещаются на экран, нет нормального поиска.

Спрашивается: если веб-приложения так активно работают с данными, то почему в браузере нет нормальной базы? С плоскими таблицами, проверкой целостности, NOT NULL, джоинами и так далее? Чтобы любой открыл схему и сразу понял, что к чему. Ведь когда схема открыта, каждый видит, что и где хранится. При попытке добавить лишнюю таблицу коллеги скажут: друг, эти данные уже хранятся здесь. А когда у вас один KV на всех, каждый тихонько подсирает в него свое барахло. Это проще, чем читать проект или спрашивать коллег, что где лежит. Проще дернуть бек и положить данные под своим ключиком – и плевать, что так поступают пять других разработчиков.

Что самое ужасное и что заставляет меня чуть ли не скрипеть зубами от досады – так это то, что лет десять назад был сделан шаг(!) в правильном направлении. Появился стандарт WebSQL, предлагавший SQL в браузере. Все по классике: таблицы, типы, not null, реляционная алгебра. В качестве бекенда – Sqlite, который мало того, что является общественным достоянием, так и работает в каждом(!) устройстве. Оглянитесь вокруг: на каждом ноуте, компе и смартфоне работают много-много Sqlite-баз. Интегрировать ее в браузерер и прокинуть через JavaScript- апишку, пусть даже в ограниченном виде, должно быть нетрудным делом.

Казалось бы, в вебе была возможна нормальная работа с данными. Но нет! Постепенно поддержку WebSQL выкинули изо всех браузеров, а в 2024 году спецификацию прикрыли. Что мы получили взамен? Ублюдочные LocalStore и IndexedDB, унылые хранилища по ключу.

А ведь реляционная база в браузере – это только начало! Можно было б пойти дальше и сделать бинарный формат для синхронизации серверной базы с клиентской. Сегодня все базы работают в бинарными данными, и нужно только написать спецификацию. Представьте: выполняешь запрос, и бинарный поток из базы сразу идет клиенту безо всяких жысонов и сериализаций. Там они подхватываются в Sqlite. Просто, доступно, открыто.