14 июля 2026 года InfoQ рассказал о выступлении разработчика Seph Gentle, который предложил довольно амбициозную идею: если приложения правда должны жить дольше одного релиза и одного вендора, им нужен другой подход к данным. В центре этой идеи — эволюция схем данных: схема хранится прямо в заголовке файла, а сам формат изначально проектируется так, чтобы переживать новые версии программ, параллельную разработку и чужие расширения без потери содержимого.
Gentle представил эту концепцию на local-first конференции, где закрывал программу докладом о «живучем» формате данных, сообщает InfoQ. Его тезис звучит просто и неприятно узнаваемо для любого, кто хоть раз вытаскивал старые данные из мертвой CRM, самодельного SaaS или внутреннего сервиса: у рынка по-прежнему плохой выбор между локальным софтом, который часто заперт на одном устройстве, и облачными системами, где данные живут ровно до тех пор, пока провайдеру интересно их обслуживать. В ответ он описал почти утопический, но технически внятный сценарий local-first ОС, где приложения делят общий слой данных и могут эволюционировать независимо друг от друга.
Ключевая проблема здесь не синхронизация и даже не UX, а формат хранения. По версии Gentle, хороший формат для долгой жизни должен быть самодокументируемым, статически типизированным, пригодным для сетевой синхронизации и потоковой передачи, а еще уметь не выбрасывать чужие поля, которые текущая версия программы пока не понимает. На бумаге это звучит как список требований, который любят все и не выполняет почти никто. В реальности разработчики обычно выбирают знакомый компромисс: JSON удобен для старта, но многословен и слабо типизирован; Protocol Buffers и Cap’n Proto компактнее и строже, но полагаются на заранее согласованные внешние схемы. Пока схема доступна и все команды синхронны, это терпимо. Как только данные начинают жить отдельно от исходной кодовой базы, начинается археология.
Именно поэтому Gentle предлагает встраивать схему прямо в первые байты файла. Тогда любой инструмент, открывающий файл, видит не просто набор байтов, а описание структуры, с которой можно работать без отдельного schema-файла и без надежды, что кто-то его не потерял по дороге. Для демонстрации он использовал экспериментальную реализацию на Rust под названием schemaboi. Механика такая: при открытии файла схема из его заголовка сливается с внутренней схемой приложения. Если каких-то полей в файле нет, они заполняются значениями по умолчанию. Если в файле есть поля, которых приложение еще не знает, они сохраняются, а не исчезают после первого же перезаписывания. Для документов, настроек, пользовательских профилей, офлайн-кэшей и любых данных, которые должны переживать миграции между версиями, это уже не мелочь, а разница между «обновились без боли» и «почему половина атрибутов у клиента пропала».
Самое интересное в этой истории — не обычная обратная совместимость, а то, что Gentle называет sideways compatibility, то есть «боковой» совместимостью. Обратная совместимость всем знакома: новая версия приложения открывает старые файлы. Прямая — наоборот: старое приложение хотя бы не ломается на новых файлах. Но в реальной жизни данные часто меняют не по очереди, а параллельно: одна команда добавила поле для аналитики, другая — собственный признак, третья вообще пишет свой клиент к тем же данным. Если идентификаторы полей выдаются просто по порядку, рано или поздно кто-то столкнется лбами. Поэтому Gentle предлагает использовать глобально уникальные идентификаторы полей, а не инкрементные теги. Иначе говоря, он хочет, чтобы формат с самого начала предполагал отсутствие единого диспетчера, который раздает номера и разрешает спор между тремя командами и двумя форками.
Для разработчиков здесь есть и практическая памятка по тому, что в схеме менять безопасно, а что нет. По словам Gentle, добавление необязательных полей или новых вариантов enum обычно проходит безболезненно. А вот превращать поле из необязательного в обязательное, переименовывать его или менять тип — уже рискованный маневр. Это звучит не как новость, а как суровое напоминание о том, что проблемы совместимости редко возникают из-за злого умысла. Обычно они появляются, когда кто-то решил «слегка почистить модель», а через полгода выяснилось, что старый мобильный клиент, партнерская интеграция и внутренний экспорт жили по другим правилам. В этом смысле доклад Gentle любопытен тем, что он не обещает магию, а наоборот защищает скучную дисциплину маленьких, постепенных изменений. В пример он приводит email и HTTP — системы, которые дожили до нашего времени не потому, что были идеальны, а потому, что терпели эволюцию лучше, чем громкие попытки все переделать начисто.
Для русскоязычной IT-аудитории здесь сразу несколько понятных сценариев. Первый — продуктовые команды, которые одновременно поддерживают веб, мобильные клиенты, десктоп и offline-first режимы. Второй — компании, которые хотят меньше зависеть от центрального бэкенда и при этом не готовы превращать каждое изменение структуры в согласование на полквартала. Третий — рынок внутренних инструментов, где данные нередко живут дольше команды, написавшей сервис. Везде, где есть локальные файлы, синхронизация, пользовательские документы или долгоживущие записи, эволюция схем данных быстро перестает быть красивой архитектурной темой и превращается в прямую экономию времени на миграциях, интеграциях и разборе полетов. Плюс у подхода Gentle есть еще одно полезное свойство: он немного возвращает контроль пользователю. Если данные описывают себя сами, приложение уже не единственный переводчик с «внутреннего диалекта» на человеческий.
При этом сам автор идеи аккуратен в выводах. По данным бенчмарков, его формат заметно компактнее и быстрее JSON, но проект пока остается экспериментальным. Gentle отдельно упоминал каноническое кодирование для content-addressable систем и поля в стиле ATProto с семантикой must_use, однако до промышленного стандарта здесь еще далеко. Главный вопрос теперь не в том, можно ли встроить схему в файл, а в том, готовы ли экосистемы отказаться от привычки считать формат данных внутренней деталью приложения. Если да, эволюция схем данных может стать не темой для красивого финального доклада, а нормой для софта, который не ломается от собственной истории.