Pull to refresh
375
0

Разрабатываю API более 10 лет

Send message

Хм. А назовёте платформу, качество пакетов для бэкенда к которой не хромает? Установим бейзлайн, так сказать.

Я тут делал одно тестовое задание на Руби, вот буквально — прототип накидать. Остался в полном недоумении, зачем в 2022 году это использовать.

Гемов мало, по сравнению с node.js — просто смехотворно. Даже самые популярные документированы исключительно плохо. А учитывая возможность расширять синтаксис, которой активно пользуются всякие фреймворки, программирование превращается в какую-то череду магических заклинаний — там подсмотрел один кусочек тайного знания, тут другой, всё в месте вроде б как-то пыхтит (правда, совершенно непонятно, как). Шаг влево-шаг право — и всё превращается в тыкву.

Как угодно. Просто закончим на том, что раздел «Чем gRPC лучше REST» вашей статьи несостоятелен, поскольку вы отказываетесь даже дать определение того, что вы имеете в виду под «REST», не говоря уже о доказательствах заявленного тезиса.

В указанной публикации не написано, какой парсер / сериализатор JSON используется, а без этого сравнение некорректно (т.к. сравнивает не производительность «REST» против gRPC, а производительность изкоробочных .NET-реализаций).

P.S. Ваши попытки прикрыть банальное незнание терминологии болтовнёй про контекст выглядят глупо. Дайте строгое определение, что вы с чем сравниваете.

Я, видимо, что-то пропустил.

Хорошо, вернёмся на шаг назад. Вас же не затруднит предоставить какие-то ссылки в подтверждение тезиса «у REST не очень хороший перформанс в сравнении с gRPC», да?

Автор знаком с graphql?

Да

Какие ISearchItemViewParameters...?

Затрудняюсь ответить на этот вопрос.

Тезис 1: gRPC — это имплементация REST-архитектуры поверх протокола HTTP/2 с использованием формата Protobuf для передачи данных. gRPC-система удовлетворяет всем критериям Филдинга, и даже в некотором смысле явлеяется более «REST» чем стандарные JSON-over-HTTP API, которые принято обозначать словом «RESTful», поскольку является, как изящно выразился Филдинг, gRPC является «hypertext-driven» системой, если рассматривать .proto-файл как формат гипертекста.

Тезис 2. Если под «REST» понимать сложившуюся парадигму разработки т.н. RESTful API, которая, грубо говоря, сводится к широкому и семантичному использованию фич протокола HTTP (HTTP-глаголов, статус-кодов ответа, передачи метаданных в заголовках, URI как идентификатор ресурса и т.п.) то совершенно непонятно, какие могут возникнуть накладные расходы, если в качестве формата запроса и ответа использовать Protobuf. Более того, REST на этом фоне выигрывает, поскольку явные метаданные (метод запроса, URI, заголовки) можно читать, не вычитывая тело ответа, и тем самым гораздо эффективнее реализовать multi-layered системы.

Тезис 3. Если под «REST» понимать строго RESTful API с использованием текстовых форматов данных (JSON/XML), то, разумеется, да — 1) JSON более многословен и 2) его сложнее парсить.

По поводу первого — голый JSON никто по сети не гоняет, вообще-то в мире есть gzip. JSON+GZIP на реальных примерах отличается от протобуфа в пределах статистической погрешности в объёмах (вот исследование Auth0, например: https://auth0.com/blog/beating-json-performance-with-protobuf/)

По поводу второго в интернете полно мифологии, но нет никаких реальных цифр. Да, это правда — многие мейнстримовые JSON-парсеры очень медленные. Но вообще-то они медленные потому, что всем наплевать на накладные расходы JSON-парсера. А если не наплевать — то вон разработчики simdjson заявляют, что добились производительности в гигабайты в секунду: https://github.com/simdjson/simdjson — и что-то я сомневаюсь, что protobuf быстрее.

Наконец, не надо забывать, что мало распарсить протобуф — надо его ещё конвертировать в структуры данных языка. И тут как бы внезапно во многих платформах это придётся делать… через JSON. Ну там браузеры, например, никаких ваших бинарных форматов не поддерживают, так что протобуф надо сначала распарсить, а потом из него JS-объекты сгенерировать, что работает в лучшем случае со скоростью JSON.parse, а в худшем — накладные расходы на две конвертации просто складываются.

gRPC тогда — тоже REST. Он поверх чистого HTTP-работает и никаких REST-парадигм не нарушает (насколько мне известно).

У REST не очень хороший перформанс в сравнении с gRPC.

Хотелось бы увидеть каких-то доказательств этого утверждения. Что вообще подразумевается под «перформансом»? Накладные расходы на сериализацию-десериализацию? Ну так шли protobuf а не json/xml, если тебе это важно.

Ну и, традиционно, автор понятия не имеет, что такое REST.

Сказал бы, что очень рад за вас. Такая же нога и не болит! Хорошо же.

Только я просто не верю, извините.

Так я и хочу задачи выполнять, а не праздновать.

Я лично просидел 1.5 года на Дебиане, и слез с него в итоге с формулировкой «праздники надоели». APE-файл смог проиграть — праздник. RAR-архив распаковался без кракозябров — праздник. Музыкальные файлы стали дабл-кликом открываться в нужном плеере — праздник. И так далее, и тому подобное.

Многовато праздников лично для меня, переизбыток дофамина получается, да так и спиться недалеко.

Уголь, полученный химически разложением углекислого газа (точнее будет сказать даже не уголь, а графит) не будет содержать никакой «дряни». А уж радиация (которая в природном угле в основном возникает за счет примесей урана) там может взяться, только если кто-то специально добавит радиоактивных материалов.

Да вот только метан и уголь нужны только для того, чтобы их обратно сжечь. А полимеры сами по себе проблема. Карбонаты зато много где используются, ну и вообще могут быть просто захоронены.

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

Раз уж на то пошло, самый эффективный естественный способ улавливания CO2 — болота. Они консервируют огромные объёмы углерода в виде торфа.

Любой лес — сбалансированная система, он поглощает CO2 только в фазе роста, который через несколько лет закончится. А вот болото может расти практически бесконечно.

Ещё, кстати, отличный способ связывания углерода — деревянная мебель и постройки из дерева. Вырастил лес, распилил его на пиломатериалы, посадил новый. Правда т.н. экологам этот способ почему-то не нравится.

Ну тогда непонятно, чего ж Филдинг возмущался, если любой апп из стора соответствует его правилам.

Для людей, которые наблюдают за работой W3C, в выступлении Филдинга-2008 ничего нового нет. Тим Бернерс-Ли, Филдинг и другие отцы-основатели очень-очень сильно топят за «семантический веб», т.е. требуют, чтобы все данные в мире были размечены и машиночитаемы. Соответственно, очень сильно расстраиваются современному подходу, когда каждый изобретает свой формат API, семантика данных и операций которого описана в доках (т.е. немашиночитаема). Отсюда и филдинговский крик души.
Вновь замечу, пойнт не в этом, а в том, что можно объявить любую систему соответствующей REST. Потому что «implicitly labeled» можно почти что угодно назвать.
> Всё это не означает, что клиент должен быть «безвольной пешкой» и абсолютно все свои действия согласовывать с сервером.

Вопрос не в согласовании действий, а в том, что по Филдингу клиент не должен содержать никакого *кода*, наприсанного специально для работы с REST API, всё должно работать на представлениях медиатипов.
По-моему, фраза «клиент должен начинать работу с REST API, не обладая никаким априорным знанием помимо начального URI и набора медиатипов» достаточно однозначно трактуется. Вы можете считать иначе, конечно, ваше право.

Information

Rating
Does not participate
Location
Россия
Registered
Activity