Комментарии 10
Главным ограничением протокола является, что он работает поверх HTTP/2. Это полностью (на данный момент) исключает его использование в браузерах.
А как же grpc-web ?
TL;DR
Если нужен чат или браузерная mmo расмотрите websocket, только сразу продумайте как будете балансировать это на бекенде. В целом так же это неплохое решение когда вам нужен легковесный протокол один-ко-многим.
Если вы хотите создать нерушимый контракт между двумя бекендами в виде единого файлика то используйте grpc.
Если вам критически важно число RPS между бекендами и вы не используете node.js(на этой платформе разницы между бинарным протоколом и REST over HTTP2 практически не будет) а так же скорее всего Python/Ruby/PHP, то опять же выбирайте grpc.
Если в описании проекта часто встречается рядом Java и Enterprise и не встречаются слова Android, iOS а корни проекта берут начало из нулевых или конца 90x то берите SOAP. Если там где-то по тексту встречается IBM или mainframe то точно берите, не прогадаете, могут еще что похуже впихнуть.
JSON-RPC - не видел что бы использовали в естественной среде обитания. Кому нужен стандарт если всегда можно поломать рамки REST своим RPC-велосипедом.
GraphQL - хорошо расписан у автора. REST велосипедостроение с api/users?...&fields=[name,surname] возвели в стандарт. Возможно хороший выбор для SPA фронтендеров.
Во всех остальных случаях лучше выбрать обычный REST. Как кухонный топор для рубки мяса, дома есть у каждого. Просто внедрять, дебажить и тестировать.
Не-REST запросы сложно будет покрыть кэширующим слоем через nginx например, потому что прямой путь /api/user/{id} превращается в абстрактный /api/ где user/{id} в теле запроса может отличаться. Сложно будет понять что можно кэшировать, а что нет.
Исключает использование в браузерах из-за HTTP/2? Очень странно. Я вот запускаю swagger через браузер и вижу в логах сервера, что запросы от swagger приходят по HTTP/2.
Мощно вы записали сразу JSON-RPC что никто не использует, при том, что в ряде индустрий это прям основной протокол.
Graphql имеет смысл использовать, если у вас nocode бекенд, отсутствует бекендер, или вы хотите его разгрузить. Например он будет заниматься интеграциями а вы пилить crud-ы. В таком случае вы существенно ускорите разработку. Ещё одним неоспоримым преимуществом является типизация, которую не всегда вам может обеспечить условный бекендер питонщик. Нынешние graphql платформы вроде hasura и apollo могут также предложить неплохую производительность по сравнению с бекенд api. Если же ваш проект это только crud-ы и у вас есть свободный бекендер то вы можете наоборот потерять в скорости так как вся работа по получению и обработки данных переносится на ваши плечи(как фронтендера)
HTTP — это простой текстовый протокол для передачи любого контента
Во времена http/1.0. А потом появились keep alive, cache control, поддержка etag, h2/hpack..
Главным ограничением протокола является, что он работает поверх HTTP/2. Это полностью (на данный момент) исключает его использование в браузерах.
Не много не верно, мы можем использовать его в браузерах но через посредника например через Envoy
А пробовал кто то gRPC в HTTP3 интересно в третьей версии все так же требуется посредник или нет?
Клиент-серверное и межсервисное взаимодействие: разбираемся в REST, GraphQL, RPC и WebSocket