начнём банально с того, что в HTTP API & REST контроль полностью на стороне сервера, что чаще всего не позволит клиенту перегрузить его.

с GraphQL у клиента по умолчанию довольно много контроля и наивная имплементация сервера положится одним через-чур сложным запросом наглухо. Есть несколько методик защиты GraphQL от DoS атак, но в целом над этим приходится думать больше чем в RPC-подобных протоколах.

написать HTTP API на Go - по сути раз плюнуть.
написать на Go GraphQL API - дороже по времени (значительно дороже когда впервые).

Вполне заменим на json-rpc ))

А зачем вообще люди идут на в gql?

у меня не особо много опыта в работе с JSON-RPC, но в целом у меня были причины идти на сторону GQL, точно уже не помню, надо восстанавливать память

graphql будет поудобнее для клиентов

это же дети читают!

чтобы между сервисами пообщаться, тут json-rpc, а другим отдавать лучше наверное graphql

У других что, лапки?

я когда brainstorm’ю очередную идею - сразу описываю API на GraphQL Schema (IDL), мне очень нравится!

в итоге получается decoupling клиента и сервера. С RPC всегда tight-coupling, если например на клиенте появилась нужда в неком датасете для новой view’шки, то мне не нужно на сервере отдельный endpoint для этого создавать, frontend’щик просто пишет себе query на то что ему надобно:

{
 group(id: “x”) {
   messages(after: 354, limit: 10) {
     body
     author {
       id
       groups(limit: 10) {
         id
         name
       }
     }
   }
 }
}

аля “дай мне из последних сообщений в группе x имена первых 10 групп в которых находятся их авторы”

руки крюки)

Если у тебя много сущностей с большим количеством связей между собой и приличным уровнем вложенности, графкуль удобнее поддерживать и сохранять консистентность апи. Плюс сразу из коробки распараллеливание, батчинг запросов, документация, плейграунд.  А на все проблемы которые были актуальны году так в 2015 уже есть решения)

с RPC/REST в данном случае придётся либо специальный endpoint создавать, либо поочерёдно грузить. Если у нас от мобилки к серверу 300мс задержка то 3 последующих запроса будут длиться почти секунду в лучшем случае

да и в итоге GraphQL Schema может заменить документацию https://twitter.com/romshar/status/1260583519694315522

Интерактивная документация все равно круче, генерится она из схемы в том же gqlgen и очень достойно выглядит) query builder там есть с автокомплитом, красота одним словом)

GraphQL схема очень близка к коду, десинхронизация очень маловероятна

introspection так вообще всегда актуален

А что у вас для gql?

Тоже. Не юзаешь playground этой либы?