Многие из нас используют текстовый формат обмена данными (JSON) для связи серверных и клиентских частей приложения. Как и многие другие текстовые форматы, JSON легко читается, может использоваться практически с любым языком программирования, для которых существует готовый код для создания и обработки данных в формате JSON. Но есть ли другие форматы обмена данными, которые могли бы быть полезными нам в процессе разработки веб приложений (и не только)?

1. Трансфер данных:
есть ли жизнь за
пределами JSONa

2. Who am I?

3. https://heliumhealthcare.com/

5. Что такое трансфер данных?
XML, JSON, YAML, BSON, etc.
Что нужно для удачного трансфера данных?
(что нужно для того, что бы 2 объекта поняли друг-друга)
или протокол:

6. XML
XML означает Extensible Markup Language, с акцентом
на markup (разметка). Вы можете создавать текст и размечать его при
помощи обрамляющих тегов, превращая каждое слово, предложение или
фрагмент в идентифицируемую, сортируемую информацию.
Создаваемые вами файлы, или экземпляры документа, состоят из
элементов (тегов) и текста, причем элементы помогают правильно
понимать документ при чтении на бумаге или даже обрабатывать его в
электронном виде.
“+” “-”- избыточный синтаксис;
- размер документа больше, чем документа в других
форматах передачи текстовых данных;
- содержит метаданные, и одновременно является
языком взаимодействия открытых систем;
- для большого количества задач можно использовать
более простые решения;
- отсутствие общепринятой методологии;
- неоднозначность моделирования;
- не содержит язык поддержки для типов данных;
- сложное использование пространств имен.
- легко читается при правильном формате;
- не зависит от платформы;
- нет общепринятой методологии для моделирования
данных в XML, в то время как для реляционной
модели и объектно-ориентированной такие средства
разработаны и базируются на реляционной алгебре,
системном подходе и системном анализе;
- в результате большой гибкости языка и отсутствия
строгих ограничений, одна и та же структура может
быть представлена множеством способов.

7. JSON
JSON (англ. JavaScript Object Notation) — текстовый формат обмена
данными, основанный на JavaScript. Как и многие другие текстовые
форматы, JSON легко читается людьми.
“+” “-”
- нет синтаксиса для задания типа объекта;
- много синтаксического мусора.
- трудно читается и анализируется пользователем,
нет визуализации;
- меньший объем данных (по сравнению с XML);
- почти неограниченные возможности расширения;
- легко преобразовать в структуру данных для
большинства языков программирования (числа,
строки, логические переменные, массивы и так
далее);
- многие языки программирования имеют функции и
библиотеки для чтения и создания структур JSON.

8. YAML
YAML — человекочитаемый формат сериализации данных,
концептуально близкий к языкам разметки, но ориентированный на
удобство ввода-вывода типичных структур данных многих языков
программирования. Название YAML представляет собой рекурсивный
акроним YAML Ain't Markup Language («YAML — не язык разметки»). В
названии отражена история развития: на ранних этапах язык назывался
Yet Another Markup Language («Ещё один язык разметки») и даже
рассматривался как конкурент XML, но позже был переименован с целью
акцентировать внимание на данных, а не на разметке документов.
“+” “-”- уступает в производительности;
- при написании существуют дополнительные меры
предосторожности. Даже если вы не учители один
пробел в отступах, ваш код может перестать
работать;
- имеет менее зрелую экосистему.
- нет ограничивающих символов = легче чем XML &
JSON;
- более понятный для чтения;
- YAML - это надмножество JSON, вы можете парить
как JSON, так и YAML-код с помощью парсера (YAML
парсера).

9. Protocol Buffers
Protocol Buffers (a.k.a., protobuf) - протокол сериализации (передачи)
структурированных данных, предложенный Google.
По замыслу разработчиков, сначала должна быть описана структура
данных, которая затем компилируется в классы. Вместе с классами
идёт код их сериализации в компактном формате представления.
Protocol Buffers не предназначен для чтения пользователем и
представляет собой двоичный формат. Для десериализации данных
необходим отдельный .proto-файл, в котором определяется формат
сообщения.

10. BSON имеет аналогичную проблему с избыточными данными. Он также
включает в себя все ключи.
Что на счет бинарного JSONa?
Рассмотрим пример:
JSON: {"hello": "world"} (17 байт)
BSON: <16 00 00 00 02 h e l l o 00 06 00 00 00 w o r l d 00 00> (22 байта)
ProtoBuf vs JSON: Представьте, что вы передаете данные с помощью JSON.
Это может выглядеть примерно так: {«type»: «ping», «time»: 123456789}, что
имеет вес в 32 байта. Тут содержится 2 + 3 + 3 + 2 + 1 = 11 байта
ограничивающих символов плюс 4 + 4 + 4 = 12 байт имен строк, составляющих
23/32 байта ~ = 71% избыточных данных. ProtoBuf, с другой стороны,
эффективно сериализует данные в двоичные файлы, не теряя никакой
информации, которая, как оказалось, имеет длину 7 байт, и все еще способная
различать два сообщения разных типов: <0A 05 08 95 9A EF 3A>
Сравним?

11. 7 байт вместо 32 это победа?
- за счет того, что protobuf определяет формат сообщения в proto-файле, нам не
нужно передавать имена полей а так же ограничивающие символы. Это делает
вес нашего сообщения гораздо меньше;
- за счет типизации полей в тех самых proto-файлах, использование protobuf
уменьшает вероятность ошибки (отправки не верных данных).
- proto-файл может так же служить документацией вашего API.
- может использоваться как схематическое отображение данных (schema).

12. Когда лучше НЕ использовать:
- молодые стартапы;
- большой размер пакетов;
- массивная архитектура приложения;
Когда использовать:
- большой поток данных;
- экосистема использующая несколько
различных языков;
- хочется.

13. Как это работает?

14. Client Server
Service Service
car.proto
encode
load load
decode encode decode
message

15. Load .proto-file
Encoding Decoding

16. https://developers.google.com/protocol-buffers
https://github.com/dcodeIO/ProtoBuf.js/

18. Thank you!