Граф удобен для фронта когда у тебя нету контракта протокола а есть модель общая с беком и ты сам делаешь «джоины»

Rpc общение микросервисов с контрактом например на протобуфе и генератором в рест и grpc

```

there might be a case for RPC for inter-service-communication and i'd even go as far as that every venture here does RPC over HTTP sometimes.

i did read your initial question as if you'd like an answer from the customer side of view and for that nobody would want to interface with someone providing an RPC API, because of the tight coupling you mentioned.

for internal use i think it's ok.

graphql OTOH is not suited for inter-service-communication, IMHO.i

don't know about gRPC. it uses protobufs which seemed incredibly weird to use back in 2011.
```



получил такой ответ от одного из бэкэров

Все правильно. Графкуэль- слишком дорого для общения между сервисами

gRPC - по сути стандарт общения между сервисами сейчас

json - неоправданно большая нагрузка для сети в данном случае

почему?

http/2 + gzip/brottli уже не справляются?

Нет

в каком кейсе например, чтобы знать...

Смотри:
Допустим у нас месседж - строка и инпут:
В джсоне- это все превращается в строку с символами, названиями полей

так

В protobuf/thrift - это будет только строка и число

Без всего остального

Потому что парсер будет знать, что:
1 поле в пакете - строка, считать байты длины, считать строку этой длины.
После этого будет число - считать число

И здесь речь не только о сети

Ещё и нагрузка на цпу

+ структура документа известна, остается только замапить

а если мы отважные хакеры, то можем вообще не парсить, а обрабатывать запрос просто идя по памяти