GraphQL это язык, на котором клиент обращается к серверу. Тебе, как разработчику API, нужно написать переводчик GQL в данные, как ты это сделаешь уже другой вопрос. У нас слоистая архитектура такова: 1. transport (transmit, authenticate) - отвечает за передачу данных и аутентификацию клиента, может быть HTTP(s), может быть WS(S), в нашем случае это https://github.com/qbeon/webwire-go 2. graph (parse, validate, authorize) - отвечает за парсинг, валидацию и авторизацию. Вызывает resolver функций для каждого поля графа. За парсинг у нас отвечает библиотека https://github.com/graph-gophers/graphql-go, а авторизация происходит в самих resolver функциях на основе тех данных, которые нам 1 транспортный уровень передал о клиенте. 3. loaders (batch, cache) - отвечает за batching и caching, грубо говоря на этом слою устраняются лишние engine-call'ы, если какие-то entity уже имеются в кэше или уже запросились другим resolver'ом, то мы его не дублируем 4. engine interface (engine capabilities) - это абстрактный интерфейсный уровень. Каждая реализация движка сервиса должна полностью воплощать этот интерфейс 5. engine (business logic, databases) - отвечает за бизнес логику и работу с бд, обязан полностью воплощать интерфейс. У нас обычно 2 движка: mock & production, mock тупо в памяти, production на основе какой-либо бд

наивная реализация GQL, где у нас запрос в бд в самом резолвере может обернуться катастрофой. Например представим кейс, где нужно запросит 100 пользователей и 100 друзей каждого из них. query { users(limit: 100) { id firstName lastName friends(limit: 100) { id firstName lastName } } } В наивной реализации у нас получится 100 * 100 = 10.000 запросов на бд, а это катастрофа, это одним запросом валит API. если же написать с 3ей прослойкой loader, то всё это превратится в 2 round-trip'а на бд, первый качает пользователей, второй - их друзей. т.е. resolver'ы обращаются к loader'у и просят вернуть им пользователя Х, loader аккумулирует все запросы и в конце 100 резолверов превращаются в 1 список id'шников пользователей, который легко обрабатывается любой бд. loader по истечению 10 мс вызывает engine.getUsers(ids) и разблокирует все резолверы вернув каждому запрошенного пользователя, потом вызываются уже резолверы друзей, и в лучшем случае, у многих юзеров будут совместные друзья и loader устранит лишние повтряющиеся id, а уже считанных пользователей возьмёт из кэша.

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

ну тогда желаю вам удачи с tight-coupling'ом. Я им уже наелся, спасибо, мне хватит. я лучше 1 раз напишу качественный API, нежели на каждую версию приложения писать новые endpoint'ы.

ну тогда желаю вам удачи с tight-coupling'ом. Я им уже наелся, спасибо, мне хватит. я лучше 1 раз напишу качественный API, нежели на каждую версию приложения писать новые endpoint'ы.

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

Как эт не возникает? Абсолютно тож самое

ну как же. я сам себе эскуэль накатал какой угодно сложности, обмазал индексами и вуаля!

Кроме gRPC

1 раз и качественно. я такого никогда не видел. тем более с какими то сложностями вроде graphql

Можешь тоже сам все написать

что REST, что gRPC это формы RPC a RPC это такой-же tight-coupling, который мне лично уже так осточертеть, что я решил нехило так рискнуть и перейти на совершенно иной подход, т.е. GQL

можно. пока у вас 3 ендпоинта. но тогда зачем graphql

Видимо потому что удобнее местами?

так как вы могли это видеть, если вы работали с REST? там 1 раз не прокатит, там постоянно нужно обновлять и оптимизировать

Вопрос в том, что при изменении сущности на бэкенде в случае реста клиенты не отвалятся. С gql - вполне себе слохнут

Ещё удобно микросервисам дальше прокидывать

В смысле?

Ну вот QueryLanguage - это про планирование иерархии данных. RPC - про планирование запросов клиента.

Ну вот есть у тебя табличка А и связанная с ней табличка Б. В какой-то момент ты рвешь реляционную связь между ними и втыкаешь туда табличку В. Т.е. связь получается А->В->Б. В этот момент gql побуждает переписать запросы на клиентах, рест - клиенты и не в курсе, ничего не ломалось

совершенно верно. И так сложилось, что я столько времени постоянно тратил на написание новых endpoint'ов, что в один прекрасный день я сказал: "ребята фронтендеры, идите-ка вы все нах@й, я увольняюсь, я заебался постоянно изменять и проверять API по любому изменению UI". GQL мне лично позволил написать 1 API, который можно использовать как угодно, без особых потерь производительности. Да, я потратил уйму времени, чтобы понять как правильно реализовать граф, но теперь сам для себя понимаю, что оно того стоило, что лучше таки 1 раз написать правильно и херачить потом запросы как угодно... ну блин.. это все-равно что вам пришлось бы переписывать бд каждый раз когда меняется API, ну это же п@зд€ц, не зря же изобрели SQL, чтоб можно было 1 раз написать нормальный движок и не париться вообще что там нужно API'шке, что нужно то и запросит.

совершенно верно. И так сложилось, что я столько времени постоянно тратил на написание новых endpoint'ов, что в один прекрасный день я сказал: "ребята фронтендеры, идите-ка вы все нах@й, я увольняюсь, я заебался постоянно изменять и проверять API по любому изменению UI". GQL мне лично позволил написать 1 API, который можно использовать как угодно, без особых потерь производительности. Да, я потратил уйму времени, чтобы понять как правильно реализовать граф, но теперь сам для себя понимаю, что оно того стоило, что лучше таки 1 раз написать правильно и херачить потом запросы как угодно... ну блин.. это все-равно что вам пришлось бы переписывать бд каждый раз когда меняется API, ну это же п@зд€ц, не зря же изобрели SQL, чтоб можно было 1 раз написать нормальный движок и не париться вообще что там нужно API'шке, что нужно то и запросит.

Просто вы так рьяно отстаиваете позиции gql на мотивации "лично мне вкатило", при том, что на него никто и не нападал... GQL - вполне себе норм инструмент, никто и не против. Но на своем круге задач. Не стоит обливать грязью старый добрый rpc, основываясь на своем узком опыте.

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

Тебе никто не мешает делать это как и в ресте- решая на беке, а можно вообще добавить ещё одно поле и добавить депрекеитид старому

давайте просто представим соцсеточку и профиль пользователя у которого 4к друзяшек. нам надо этот список получить. как будем делать?

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

Просто вы так рьяно отстаиваете позиции gql на мотивации "лично мне вкатило", при том, что на него никто и не нападал... GQL - вполне себе норм инструмент, никто и не против. Но на своем круге задач. Не стоит обливать грязью старый добрый rpc, основываясь на своем узком опыте.

Для таких вещей всегда пагинация делается, ничего страшного не будет

Это контракт, который не обязан отражать то, что у тебя в базе

Просто вы так рьяно отстаиваете позиции gql на мотивации "лично мне вкатило", при том, что на него никто и не нападал... GQL - вполне себе норм инструмент, никто и не против. Но на своем круге задач. Не стоит обливать грязью старый добрый rpc, основываясь на своем узком опыте.

совершенно верно. И так сложилось, что я столько времени постоянно тратил на написание новых endpoint'ов, что в один прекрасный день я сказал: "ребята фронтендеры, идите-ка вы все нах@й, я увольняюсь, я заебался постоянно изменять и проверять API по любому изменению UI". GQL мне лично позволил написать 1 API, который можно использовать как угодно, без особых потерь производительности. Да, я потратил уйму времени, чтобы понять как правильно реализовать граф, но теперь сам для себя понимаю, что оно того стоило, что лучше таки 1 раз написать правильно и херачить потом запросы как угодно... ну блин.. это все-равно что вам пришлось бы переписывать бд каждый раз когда меняется API, ну это же п@зд€ц, не зря же изобрели SQL, чтоб можно было 1 раз написать нормальный движок и не париться вообще что там нужно API'шке, что нужно то и запросит.

Если таблицу В тоже надо будет отдать наружу, вот это всё станет костылем

RPC имеет право на существование, но не в большинстве Web API, по крайней мере это моё личное мнение основанное на всех выше указанных и пояснённых аргументах. Можете соглашаться, можете не соглашаться)

Так а вы на изменения UI переписывали endpoint-ы? Ну понятно, что есть перформанс и т.д., но говорить, что это был REST...

Рпц хорошо, пока описывается в парадигму запрос-ответ, а вот если надо подписываться на поток или еще что-то, все делается гораздо хуже

много дезынформации по GQL мне пришлось услышать, на которую я не могу равнодушно смотреть чес гря. Поэтому стараюсь рассказывать из своего опыта конкретные примеры и делиться своими познаниями ради общего блага. Такова суть community, бороться с дезынфой)

давайте просто представим соцсеточку и профиль пользователя у которого 4к друзяшек. нам надо этот список получить. как будем делать?

RPC имеет право на существование, но не в большинстве Web API, по крайней мере это моё личное мнение основанное на всех выше указанных и пояснённых аргументах. Можете соглашаться, можете не соглашаться)

Gql в качестве публичного апи на масштабах/вариативности данных уровня гитхаба - работа для некуйственного штата звезд-погроммистов. Реализация эндпоинта с нужной выборкой на тех же условиях - дело, доступное одиночке.

Если ее надо отдать наружу, то такие же проблемы будут и в ресте, не выдумывай

В ресте я тупо отдам ещё один эндпоинт и добьюсь прежнего поведения от имеющегося. Повторяю, клиент не узнает)

Рпц хорошо, пока описывается в парадигму запрос-ответ, а вот если надо подписываться на поток или еще что-то, все делается гораздо хуже

а потом пользователь захочет половину друзяшек удалить. 2к запросов или делаем батч-эндпоинт принимающий список id?

а потом пользователь захочет половину друзяшек удалить. 2к запросов или делаем батч-эндпоинт принимающий список id?

Рпц хорошо, пока описывается в парадигму запрос-ответ, а вот если надо подписываться на поток или еще что-то, все делается гораздо хуже

query($id: Identifier!) { user(id: $id) { friends(from: 0, limit: 100) { id name } } } тут приведён пример пагинации по 100 профилей на запрос. В резолвере мы запрещаем брать более чем 100 профилей одновременно по очевидным причинам возвращая ошибку.

Борьба с дезинфой и "хороним rpc" - разные вещи. Разъяснение неверно понятых моментов графкуля я только поддерживаю, а попытки самовосхваления за счёт других технологий - не, не поддерживаю)

Надеюсь, хотя бы с тем, что GQL хочет бОльшего от архитектуры приложения, чем rest, который можно прикрутить по-быстрому сбоку, спорить не будете?

Gql в качестве публичного апи на масштабах/вариативности данных уровня гитхаба - работа для некуйственного штата звезд-погроммистов. Реализация эндпоинта с нужной выборкой на тех же условиях - дело, доступное одиночке.

нет, тут проблема в другом, RPC хорош до тех пор, пока требования клиента не меняются. А вот когда они начинают меняться и в добавок у вас появляется более 1 клиента и каждый со своими требованиями - вот тут начинается лютый пздц

В ресте я тупо отдам ещё один эндпоинт и добьюсь прежнего поведения от имеющегося. Повторяю, клиент не узнает)

так я вроде исключительно аргументами и молвлю

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

Призыв похоронить REST "патамушта GraphQL" - так себе аргумент)

это пока ещё ибо реализации библиотек сыроваты и mind-shift не произошёл. Ибо я лично знаю как тяжко было мне с RESTful'ского мышления переходить на (не-наивные) графы

я все аргументы привёл, опровергнуты они пока-что не были ?

смотря где и смотря в чем. Прикрути мне по-быстрому GraphQL к 1С-ке, например.

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

эээм, и чем тут REST отличается от GQL? оба принципа являются абстракциями... если бд изменится, то GQL остановится прежним, просто затронутые resolver'ы перепиши, как и endpoint'ы REST'а

И? Делаешь схему, прикручиваешь как и рест

однако всё может поменяться. По мере становления GQL стандартом может появиться много готовых-из-коробки решений, которые значительно упростят постороение API такой архитектуры

я тебе говорю: разница только в уровне, на котором сосредоточена сложность. Если у тебя есть 20 RPC-методов с фиксированным контрактом, внедрение GrapQL может оказаться для тебя лишней тратой времени.

с этим я согласен. Но мой личный опыт сложился именно так, что приложения очень сильно и часто мутируют в процессе естественной эволюции и написав эти 20 RPC-методов, ты их потом ещё 100500 раз перепишешь/удалишь/создашь ибо требования, по крайней мере у меня, менялись так часто, что мне было выгоднее потратить гораздо больше времени на изучение графовой теории, но раз и навсегда научиться делать более сложные, но более устойчивые к изменениям требований API

Вот тебе пример, где GraphQL "нивзлитит". Возьми вещи вроде OpenWeatherMap. Вот отдают они REST, и все довольны. Возьмутся поднимать GQL - и всем будет плохо.

Смотри, GQL - это про "отдать реляции наружу, пусть клиент сам определяет, что ему нужно". При наличии реальной реляции A->В->Б делать еще одну "виртуально-костыльную" А->Б для какого-то особого случая "чтобы не поломалось" хоронит нахрен всю красоту подхода GQL. В конце концов, ты граф замыкаешь... Ну и нафига? Просто ты озадачиваешь клиентов "мы тут поменяли, перепишите", и все - это верный подход GQL. Если "мы тут поменяли, перепишите" по какой-то причине "совсем-совсем нельзя", дважды подумай, прежде чем на GQL переползать.

с этим я согласен. Но мой личный опыт сложился именно так, что приложения очень сильно и часто мутируют в процессе естественной эволюции и написав эти 20 RPC-методов, ты их потом ещё 100500 раз перепишешь/удалишь/создашь ибо требования, по крайней мере у меня, менялись так часто, что мне было выгоднее потратить гораздо больше времени на изучение графовой теории, но раз и навсегда научиться делать более сложные, но более устойчивые к изменениям требований API

там вся приколюха именно в том, что с GraphQL ты ИЗНАЧАЛЬНО моделируешь ГРАФ ДАННЫХ, чтобы потом с ним работать. В REST ты изначально моделируешь запросы клиента, а потом "откуда-нибудь берешь данные". Скажем так, на старте реализация от "начал" до "получил какой-то эффект" в REST'е быстрее, и не говорите мне, что это не так. Вопрос исключительно в том, на каком пороге они сравняются по трудозатратам, и на каком моменте GQL "окупится". Вот реально, в стабильных апишках на пару-тройку эндпоинтов с 3-4 методами на каждый ты GraphQL не окупишь.

У гитхаба чёт не возникло проблем)

Да откуда такая метрика про быстрее?

давай на скорость: берем БД с одной табличкой, Go, и проверяем, кто быстрее напишет реализацию 1 метода апи с предопределенной выборкой. Я - с 1 REST-endpoint'ом, или ты с GraphQL?

Верю что его там можно юзать

Давай, ток я на скале)

Вот тебе пример, где GraphQL "нивзлитит". Возьми вещи вроде OpenWeatherMap. Вот отдают они REST, и все довольны. Возьмутся поднимать GQL - и всем будет плохо.