Правда там нет версионинга, т.к. у RAWG его на уровне API нет

Какие? Возможность юзеру выбирать то, что он хочет? Очень классно, особенно запросы к БД оптимизировать под нагрузкой, наверное.

почитай ссылку

там всё более чем подробно описано

ну ты часть можешь на протобаф переделать, ниче сложного нет там, между мс вроде хттп2 нормально работает

Как вообще этой "фигней" пользоваться, чтоб собрать формочку для сохранения данных? Наверное надо идти к бекендерам за консультацией.
Каждый ендпоинт описывается примитивными типами, нет "сложных" типов
Нет связей между типами, не известно как оптимальнее всего запросить связанные ресурсы
Жирные ответы, если не прикрутить фильтр по полям. Но даже если есть фильтр по полям, то ленивых фронтендеров, которые ими не пользуются - никто не отменял.
Нет возможности построить сложный агрегационный запрос без участия бэкендера
Из-за REST API нет возможности использовать Apollo Client или Relay, приходиться использовать Redux, MobX
Самый жирный минус:

Фронтендеры пишут кучу бойлерплейт кода, для получения связанных данных между ресурсами. Часто гадают на кофейной гуще. Часто с матами. Лучше и правильнее чем бэкендер, который проектировал модели и базу, никто такие связи на клиенте не построит.

вот если коротко

Я вот тоже думаю над этим.

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

а вообще по тсп же можно напрямую долбанутся к мс, у тя же внутрення шляпа, не обязательно граф внутри юзать так то))

json rpc ) самый тупой и простой формат
легче чем рест в плане понимания ) но теже проблемы у фронта будут что и с рестом

Я вообще чутка (сильно) думаю переделывать, буду ставить gRpc между мс-ами, очередь пусть будет у них внутри на том же bull, а вот общение с фронтом скорее всего переедет на REST ибо я вот смотрю на этот проект и понимаю что граф тут нужен грубо говоря на 4-5% не более.

>> "не будет возможности выбирать данные на клиенте без изменения кода сервера" - это как раз хорошо, ибо надёжно

это твоё надёжно обычно заканчивается тем, что клиент сделает 10 запросов, чтобы забрать данные, вместо одного.

сабскрипшены задобаешся руками реализовывать) на веб сокетах

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

Слушая, а я вот не уточнял (может ты в курсе), у нас Angular может как-то доставить данные через gRpc ?

у нас на работе так работает, есть клиент жеж

Так я не в курсе вообще, не смотрел gRpc пока вообще. Тогда вообще можно выпилить и REST и будет чисто gRpc

Ты так пишешь, потому что, возможно, думаешь, что я о GraphQL ничего не знаю. Это не так, я читал на эту тему, и ту статью я сейчас тоже поглядел. Лично для меня аргумент вида "Нет возможности построить сложный агрегационный запрос без участия бэкендера" очень странный. Потому что в реальных условиях с GraphQL ты его точно так же не сделаешь без бэкендера. Потому что под капотом там всё равно SQL-запрос, который нужно строить (учитывая возможности конкретных СУБД) и после этого оптимизировать. Невозможно оптимально реализовать логику, заранее не продуманную на бэкенде.

"Как вообще этой "фигней" пользоваться, чтоб собрать формочку для сохранения данных? Наверное надо идти к бекендерам за консультацией." - с GraphQL ты точно так же будешь ходить к бэкендерам. Может не в первые месяцы разработки, но будешь. Когда данных переваливает за десятки миллионов, вопрос оптимизации всё поставит раком.