Comments 19
Buffer — сверхэффективная бинарная сериализация
Супер, пупер, дупер.
По факту, еще один Yet Another .
Вот эта вот возможность "на коленке" слепить сообщение и отправить, как в джейсоне, может быть иногда очень полезна. Этого в протобуфе нет, к сожалению, именно поэтому его можно использовать только в контексте похожем на rpc. Так что всё правильно говорят.
Имена или номера - у каждого подхода есть и плюс и минус. Я бы добавил в протобуф опциональную возможность использовать имена вместо номеров. Можно конечно слепить что-то поверх протобуфа, но это уже будет не то.
Всё дело в удобстве. JSON это не только веб, это и обмен данными внутри mesh-сетей iot, и в том числе возможность простой модификации и отладки.
Попробуйте то же самое сделать в формате CAN, например - тоже хороший протокол, но это будет очень некомфортно. Потому что бинарный
От такого удобства датацентры пухнут) Вот к примеру, у нас был сервер приложений и телекоммуникационная плата по проприентарному бинарному протоколу за примерно 25 тысяч. Прогрессивный менеджмент сказал, что плата очень дорого и неудобно, и заменил плату примерно 2-3 блейдами, балансером и маленькой бд.. Внутри были http и джейсоны, конечно. В итого - замена дорогой платы вылилась в почти такой же бюджет за комплектацию, увеличение в 2-3 раза места в стойке, потребление электричества вместо 90 Вт хз сколько. Хотя платы да - сложно и неудобно, хрень какая то а не программирование
Кто мешает по заданному endpoint вернуть схему для декодирования?
JSON тоже все прекрасно пока у вас 5 полей и нет иерархии. А как накрутят, заколебешься разбираться. Не говоря о классной идеи иметь опциональные поля, которые не понятно куда и как мэпятся, поскольку половина запросов/ответов идет без них.
Вот и приходится прикручивать сверху json schema, swagger и т.д. Чтобы хоть какую-то информацию получить.
Ну и разработка начиная с файла спецификации -правильный подход. Все что реализовано соответствует заданной документации.
У меня тут была куча удовольствия когда пришлось на powershell работать с json сервисами. В итоге написал свой конвертер из swagger в типы powershell. Ни кому не посоветую
Стоит отметить, что в Protobuf (3) невозможно указать обязательность поля, даже более того - все поля необязательные. А это, по-моему, самый большой минус формата.
У protobuf есть существенная проблема с большими целыми (если заранее не известно, поместится ли результат в Int64, его приходится передавать строкой, что ломает семантику и засоряет карбюратор. В JSON всё прозрачно:
iex|🌢|1 ▶ Jason.encode!(%{foo: 123456789012345678901234567890123456789012345678901234567890})
"{\"foo\":123456789012345678901234567890123456789012345678901234567890}"
Спасибо за статью. Стоит отметить что protobuf схему можно использовать не только в контексте обмена сообщениями (между сервисами, фронтом, и чем либо другим), а так же как доменные модели вашей бизнес логики. Как пример если ваши модели могут быть сериализованы из базы данных, прокручены через бизнес логику, в потом отправлены на фронтенд (или в очередь другого сервиса) вы получите возможность использовать версионированные строго-типизированные данные повсеместно, что экономит значительное количество времени на описание доменных структур и сериализаторов различных моделей и форматов.
Внутри компании при сервисном взаимодействии через Кафку или gRPC, используем protobuf.
Для API торчащих наружу используем Rest API с json, описанных в openapi контракте.
Когда клиент отправляет запрос серверу, он передаёт сообщение, которое содержит:
заголовки, включая хорошо знакомый Content-Type, указывающий формат сообщения (JSON, XML, Protobuf и т. д.);
тело (payload), в котором находятся сами данные;
статус ответа.
Мне кажется, что третий пункт не относится к запросу клиента к серверу.
Или имелось ввиду что-то другое?
Опять смешали тёплое с мягким. У protobuf есть один плюс - он занимает меньше места.
Но утверждать, что если json так это сразу schema-less говнокод - тоже не верно. Openapi для того и придумали - схема запроса, ответа, все заголовки, модели, генерация дто под практически любой язык из коробки, бери и пользуйся.
Но нет, уже которую статью подряд говорят, что json - это круто и гибко, потому что можно любое поле в запрос впихнуть. Используйте спецификации и валидацию, и нельзя будет. Детский сад.
Лучше, чем JSON: почему я перешёл на Protobuf