Естественно вытекающая из темы сериализации тема миграции данных.

Живые системы не статичны, они меняются. Найти сегодня ПО и тем более онлайн-сервисы, которые не меняются — надо постараться.

Мы в своём подходе изначально закладывали (и кажется что в 2020+ по-другому нельзя) что наш софт будет меняться и меняться часто (даже по нескольку раз в день). Причём как клиентская, так и серверная сторона. И желательно без простоев, на горячую.

И ладно если изменение косметическое (кнопку там передвинуть или анимацию заменить) — самая жесть начинается при изменении структур данных, протоколов их передачи и хранения. Надо обеспечить их безопасный перенос в новый формат, обеспечить обратную совместимость или/и поддержку старых протоколов, пока всё (и все) не обновилось.

Это кстати частая причина замедления развития проектов, т.к. делать конвертацию уже большого объёма накопленных данных (например, переписка или игровая статистика миллионов пользователей) — это либо полный останов сервиса на часы, либо делать это прямо наживую, начиная с "горячих" данных и постепенно перенося архивное. Зачастую это делают в несколько этапов, подготавливая сначала данные и уже потом накатывая новую логику.

Короче, это требует серьёзной подготовки и очень ответственного подхода (поэтому хорошие девопсы ценятся даже во времена победившего нейрокодинга) — одно неловкое движение, данные ломаются, сервис встаёт, и даже восстановление из резерва может оказаться тем ещё челленджем (кстати, поучительная история на эту тему у моего коллеги Алексея Андросова в его недавно родившемся канале).

Поэтому лишний раз стараются ничего не менять в уже работающей системе, а только добавлять, и то, осторожно. Это примерно как не выкидывать старые вещи из дома — за несколько лет проект и его данные превращаются в свалку всякого устаревшего вперемешку с новым (иногда дублирующимся). И с каждым разом поддерживать такое становится всё сложнее и сложнее. Релизы готовятся дольше, фиксы откладываются, нервозность повышается, а удовольствие от разработки падает. Это кстати не учитывают многие начинающие стартаперы-саасники (которых сегодня снова расплодилось на вайбкод-волне), они наивно экстраполируют лёгкость "начинания" на годы вперёд. В том числе по этой причине подавляющее большинство их не выживет.

Мы пацаны битые, поэтому готовимся к саппорту не когда уже пора масштабироваться, а ещё на этапе закладывания фундамента.

У нас в основе архитектуры — данные, а не команды (события, колбэки и пр.). Мы сразу закладываем то, что структуры данных будут постоянно меняться и хотим, чтобы этот процесс был максимально лёгким и дешёвым (бесплатно никак не получится, но хотя бы так). Поэтому у нас есть версионирование (слепки структур) и по возможности автоматическая конвертация из старых версий в новые (собственно, миграция).

Это позволит обеспечить обратную совместимость и постепенное обновление данных при хранении на серверах, передачи (протокол обмена — это тоже сериализованные данные).

И в том числе хот-релоад:
- сохраняем состояние в сериализованный файл (сохранёнку)
- закрываем программу
- обновляем и запускаем
- считываем старую сохранёнку
- мигрируем данные в новые структуры
- работаем дальше

В видео Дима наглядно объясняет базу механизма миграции. Может в будущих видео расскажет и детали, как мы это всё делаем.