В начале 4-й главы разбираются способы сериализации данных для передачи между приложениями.

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

Возникают ситуации, когда в системе одновременно существуют старые и новые версии кода. Например:
- сервис обновил API, но ещё не все клиенты перешли на новое
- на бэкенде регулярно выкатывают изменения, а пользователи мобильного приложения сидят на старой версии приложения
- разворачиваем новую версию кода постепенно: сначала на небольшом количестве узлов, проверяем и затем на остальных. Такой подход называется rolling update (плавающее/последовательное обновление).

Чтобы в такой ситуации у нас всё не сломалось, нужно заранее подумать о совместимости. Есть два вида:

✅ прямая совместимость — старый код способен читать данные нового формата.
✅ обратная совместимость — новый код способен читать данные старого формата.

Думаю, с поддержкой совместимости в API многие сталкивались. Например, ситуация: бэкенд уже обновили, а фронтенд ещё нет. Прямая совместимость — чтобы «старый» фронт не сломался от нового формата ответов бэка. Обратная совместимость — чтобы «новый» бэк не сыпал ошибками на старый формат запроса от фронта.

Помню, как писала наши правила для совместимости:
- поля в ДТО не меняют тип — для нового типа добавляется новое поле с новым именем и типом
- поля в ДТО не переименовываются — если изменилась семантика поля, то заводим новое поле с другим именем (например, в поле total записывали сумму без НДС, а теперь надо передавать сумму с НДС, значит нужно новое поле с другим именем totalIncludingVAT)
- новые поля не являются обязательными

В 4-й главе рассматриваются различные форматы сериализации данных:

📌Форматы конкретных языков программирования (например, Serializable в Java). Они ограничены языком, что неудобно, а также бывают ресурсоемки и небезопасны.

📌 Двоичные форматы: Thrift, Protocol Buffers и Avro. Они позволяют выполнять сжатую и эффективную сериализацию с четко определенной семантикой обратной и прямой совместимости.

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

Недостаток таких форматов: человек не может их прочитать в «сыром» виде, нужно десериализовывать.

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

В XML и JSON есть дополнительная поддержка схемы данных, у CSV схемы нет.

Недостатки текстовых форматов:
- используют больше места, чем двоичные форматы
- в XML и CSV невозможно различить число и строку, состоящую из цифр
- JSON различает числа и строки, но не различает целочисленные значения и значения с плавающей точкой и не позволяет задать их точность
- не поддерживают двоичные строки (последовательности байтов без кодирования символов). Это ограничение обходят, кодируя двоичные данные как текст с помощью Base64.

#кабанчик #сисдиз