Что выбрать grpc или graphql?

Question

[raiboon]

На стороне grpc перфоманс с точки зрения протокола и формата сериализации, с другой стороны, на стороне graphql возможность гибко задавать список необходимых полей сущностей, что улучшает перфоманс, но немного с другой стороны.

На основании каких параметров выбирать тот или иной Фреймворк/формат?

Answer 1

[Василий Банников]

Выбирай от того, как предполагается использовать.
Если ты разрабатываешь и клиент и сервер, и при этом клиент нормально умеет в grpc (не браузер) - бери grpc.
Если ты разрабатываешь только сервер, а клиенты разные с разными потребностями - тогда graphql.
Ну и никто не запрещает комбинировать - можешь сделать сервер с grpc, а клиентский api предоставлять с graphql

Answer 2

[Дмитрий Беляев]

Для внутреннего апи (например когда все клиенты пишутся в той же компании, что и апи) различные RPC протоколы (например тот же grpc) будут эффективнее.

гибко задавать список необходимых полей сущностей

Нормально спроектированное RPC в принципе не отдает ничего лишнего, при этом минимизирует потребность нескольких вызовов за раз. Это позволяет делать апи с минимально возможными издержками.
С GraphQL же придется сильно запарится, чтоб вот те данные из разных таблиц дергались через JOIN, а не через N запросов с постобработкой.

С другой стороны, если апи публичное, то общепринятые вещи типа GraphQL или REST будут предпочтительнее.

Comments

[raiboon]

> Нормально спроектированное
> не отдает ничего лишнего

Ну такое утверждение.
Отдает и никак иначе, вопрос только в количестве.
Либо мы делаем апи достаточно generic, и оно возвращает все что знает о сущностях - куча лишнего.
Либо очень узкое и... Оно и правда первые сутки "не отдает ничего лишнего", но потом у этого апи появляется больше одного клиента, которым нужны разные сабсеты данных и вот лишние данные, не говоря о том, что слишком узко написанное апи придется менять каждый второй день, когда в другом месте потребовалось на одно поле больше.