Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Виктор Гунько "Трансфер данных: есть ли жизнь за пределами JSONa"

129 views

Published on

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

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Виктор Гунько "Трансфер данных: есть ли жизнь за пределами JSONa"

  1. 1. Трансфер данных: есть ли жизнь за пределами JSONa
  2. 2. Who am I?
  3. 3. https://heliumhealthcare.com/
  4. 4. Что такое трансфер данных? XML, JSON, YAML, BSON, etc. Что нужно для удачного трансфера данных? (что нужно для того, что бы 2 объекта поняли друг-друга) или протокол:
  5. 5. XML XML означает Extensible Markup Language, с акцентом на markup (разметка). Вы можете создавать текст и размечать его при помощи обрамляющих тегов, превращая каждое слово, предложение или фрагмент в идентифицируемую, сортируемую информацию. Создаваемые вами файлы, или экземпляры документа, состоят из элементов (тегов) и текста, причем элементы помогают правильно понимать документ при чтении на бумаге или даже обрабатывать его в электронном виде. “+” “-”- избыточный синтаксис; - размер документа больше, чем документа в других форматах передачи текстовых данных; - содержит метаданные, и одновременно является языком взаимодействия открытых систем; - для большого количества задач можно использовать более простые решения; - отсутствие общепринятой методологии; - неоднозначность моделирования; - не содержит язык поддержки для типов данных; - сложное использование пространств имен. - легко читается при правильном формате; - не зависит от платформы; - нет общепринятой методологии для моделирования данных в XML, в то время как для реляционной модели и объектно-ориентированной такие средства разработаны и базируются на реляционной алгебре, системном подходе и системном анализе; - в результате большой гибкости языка и отсутствия строгих ограничений, одна и та же структура может быть представлена множеством способов.
  6. 6. JSON JSON (англ. JavaScript Object Notation) — текстовый формат обмена данными, основанный на JavaScript. Как и многие другие текстовые форматы, JSON легко читается людьми. “+” “-” - нет синтаксиса для задания типа объекта; - много синтаксического мусора. - трудно читается и анализируется пользователем, нет визуализации; - меньший объем данных (по сравнению с XML); - почти неограниченные возможности расширения; - легко преобразовать в структуру данных для большинства языков программирования (числа, строки, логические переменные, массивы и так далее); - многие языки программирования имеют функции и библиотеки для чтения и создания структур JSON.
  7. 7. YAML YAML — человекочитаемый формат сериализации данных, концептуально близкий к языкам разметки, но ориентированный на удобство ввода-вывода типичных структур данных многих языков программирования. Название YAML представляет собой рекурсивный акроним YAML Ain't Markup Language («YAML — не язык разметки»). В названии отражена история развития: на ранних этапах язык назывался Yet Another Markup Language («Ещё один язык разметки») и даже рассматривался как конкурент XML, но позже был переименован с целью акцентировать внимание на данных, а не на разметке документов. “+” “-”- уступает в производительности; - при написании существуют дополнительные меры предосторожности. Даже если вы не учители один пробел в отступах, ваш код может перестать работать; - имеет менее зрелую экосистему. - нет ограничивающих символов = легче чем XML & JSON; - более понятный для чтения; - YAML - это надмножество JSON, вы можете парить как JSON, так и YAML-код с помощью парсера (YAML парсера).
  8. 8. Protocol Buffers Protocol Buffers (a.k.a., protobuf) - протокол сериализации (передачи) структурированных данных, предложенный Google. По замыслу разработчиков, сначала должна быть описана структура данных, которая затем компилируется в классы. Вместе с классами идёт код их сериализации в компактном формате представления. Protocol Buffers не предназначен для чтения пользователем и представляет собой двоичный формат. Для десериализации данных необходим отдельный .proto-файл, в котором определяется формат сообщения.
  9. 9. 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> Сравним?
  10. 10. 7 байт вместо 32 это победа? - за счет того, что protobuf определяет формат сообщения в proto-файле, нам не нужно передавать имена полей а так же ограничивающие символы. Это делает вес нашего сообщения гораздо меньше; - за счет типизации полей в тех самых proto-файлах, использование protobuf уменьшает вероятность ошибки (отправки не верных данных). - proto-файл может так же служить документацией вашего API. - может использоваться как схематическое отображение данных (schema).
  11. 11. Когда лучше НЕ использовать: - молодые стартапы; - большой размер пакетов; - массивная архитектура приложения; Когда использовать: - большой поток данных; - экосистема использующая несколько различных языков; - хочется.
  12. 12. Как это работает?
  13. 13. Client Server Service Service car.proto encode load load decode encode decode message
  14. 14. Load .proto-file Encoding Decoding
  15. 15. https://developers.google.com/protocol-buffers https://github.com/dcodeIO/ProtoBuf.js/
  16. 16. Thank you!

×