Но у меня рест, а здесь явно лучше система. Если есть еще аналог, скажите, тоже изучу.

Попробуй еще глянуть protobuf, но это уже другая история )

Ну да, фейсбук просто для прикола его разработали, как Го для прикола разработали, да ? ))))

а тут мы сильно усложняем логику на бэкенде в угоду фронту

Попробуй еще глянуть protobuf, но это уже другая история )

Э не, я протобаф изза доты и кс и сорс движков не люблю )

Ну да, фейсбук просто для прикола его разработали, как Го для прикола разработали, да ? ))))

причем тут фейсбук? мы обсуждаем архитектуру системы. Архитектура - говно

и, кстати, разработали его в первую очередь в гитхабе, если я ничего не путаю

причем тут фейсбук? мы обсуждаем архитектуру системы. Архитектура - говно

Холивар

а тут мы сильно усложняем логику на бэкенде в угоду фронту

Я согласен сам себе усложнить бэк, ради облегчения процесса на стороне фронта.

Я согласен сам себе усложнить бэк, ради облегчения процесса на стороне фронта.

зачем? фронт должен жрать то, что ему дает бэк

зачем? фронт должен жрать то, что ему дает бэк

> Должен С чего это вдруг?

если слишком много запросов или проблемыс кэшем - надо менять обработчики и параметры к ним, но никакого "а давайте разрешим произвольные запросы" не должно быть

если слишком много запросов или проблемыс кэшем - надо менять обработчики и параметры к ним, но никакого "а давайте разрешим произвольные запросы" не должно быть

я выше это писал )

если слишком много запросов или проблемыс кэшем - надо менять обработчики и параметры к ним, но никакого "а давайте разрешим произвольные запросы" не должно быть

Graphql не разрешает произвольнее запросы

> Должен С чего это вдруг?

с того, что это два независимых компонента и между ними протокол. Для большинства вариантов бизнес-логики REST достаточен и при прямых руках вполне оптимален

а вот graphql - избыточен и усложнен

причем тут фейсбук? мы обсуждаем архитектуру системы. Архитектура - говно

Сколько людей, столько и мнений. Фейсбуку верю, что им нужно было решение, в льтернативу rest'a, чтобы снизить нагрузку. https://code.facebook.com/posts/1691455094417024/graphql-a-data-query-language/

а вот graphql - избыточен и усложнен

В каком месте ? Вполне себе не сложная штука

Graphql не разрешает произвольнее запросы

он разрешает джойнами управлять с фронта. Это хреново, это смесь логики в кучу, весь хваленый MVC/MVP сразу летит нахрен

а вот graphql - избыточен и усложнен

Ладно, попробуем немного, потом посмотрим. Тогда не буду торопиться.

В каком месте ? Вполне себе не сложная штука

так дело не в сложности написания, а в другом

Сколько людей, столько и мнений. Фейсбуку верю, что им нужно было решение, в льтернативу rest'a, чтобы снизить нагрузку. https://code.facebook.com/posts/1691455094417024/graphql-a-data-query-language/

это они просто не смогли в rest нормально

В каком месте ? Вполне себе не сложная штука

несложная на бумаге

он разрешает джойнами управлять с фронта. Это хреново, это смесь логики в кучу, весь хваленый MVC/MVP сразу летит нахрен

Джоинами чего?

Джоинами чего?

моделей

это они просто не смогли в rest нормально

Я только недавно задавал себе вопрос, а не много ли лишней инфы фронту я передаю? Которую он не юзает. Эту инфу бессмысленно было намеренно вырезать из инстанса и так же бессмысленно было создавать отдельные структуры, только для урезанного ответа для апи. А здесь, я пока вижу смысл, так как реально клиент получает то, что запросил.

моделей

Эт проблема ?

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

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

Как напишешь так и будет

Ну да)

Винду в пример ) с миллиардом дыр, за миллиарды долларов )

Любой софт в пример

Винда очень глобальный пример просто )

Кстати, на стороне Golang, в этом GraphQL жесть что творится )))) Жеееесть.

В go почти везде жесть

Если вы не достигли болевых точек REST API, решением которых является GraphQL, то можете не волноваться.

Если вы не достигли болевых точек REST API, решением которых является GraphQL, то можете не волноваться.

Я достиг. Но почему то забил на это. Но теперь попробую что нибудь.

Клиенту не принципиально. Но сам себя как разраб не буду уважать, если не постараюсь сделать лучше, чем есть сейчас.

советую почитать https://habrahabr.ru/post/326986/ https://habrahabr.ru/post/335158/ особенно комменты с плюсиками

Я только недавно задавал себе вопрос, а не много ли лишней инфы фронту я передаю? Которую он не юзает. Эту инфу бессмысленно было намеренно вырезать из инстанса и так же бессмысленно было создавать отдельные структуры, только для урезанного ответа для апи. А здесь, я пока вижу смысл, так как реально клиент получает то, что запросил.

а ты не передавай)

Эт проблема ?

да, это смешивание логики

GraphQL — ради одной точки входа создаём себе кучу проблем вроде непредсказуемого API c потенциальными дырами в безопасности.

Раз такой оптимизацией занялись, еще бы и эту часть улучшили. Например, нахрена там 4 ключа "title", если все ключи запросились одинаковые? ))))

Раки )

Ээээ, я с такой надеждой смотрел.

Сейчас досмотрю, если они там так и оставят 4 и 3 одинаковых ключа, выкину на свалку. ) Или закомичу. )

Эт проблема ?

По аналогии с SQL, если вы откроете доступ к БД, то злоумышленник может сделать SQL запрос с кучей join которые тупо повесят ваш сервер БД

да, это смешивание логики

Каким это образом ?

По аналогии с SQL, если вы откроете доступ к БД, то злоумышленник может сделать SQL запрос с кучей join которые тупо повесят ваш сервер БД

Нет не сможет, потому что есть максимальная сложность

Каким это образом ?

обычным. Фронт ничего не должен знать о моделях на бэкенде

обычным. Фронт ничего не должен знать о моделях на бэкенде

А с чего ты взял что будет? Схему определяешь ты

Ты делаешь схему и условно мапинг на то, что у тебя в беке. Никто не мешает делать доменную схему

Ну и лучше сделать один запрос, чем потом фронту делать 50

Учитывая, что там есть кэши и оптимальные резолверы

вот самое то что нужно Да, GraphQL прячет резолверы ресурсов внутрь, делая бесполезными коды ошибок HTTP, глаголы HTTP, заголовки HTTP, используемые промежуточным ПО для кеширования и контроля работы с данными. Именно об этом я и говорю, GraphQL — это «ленивое» проектирование, которое удешевляет разработку на старте проекта, но удорожает на дальнейшей разработке и поддержке.

А с чего ты взял что будет? Схему определяешь ты

да, и я определяю связи между сущностями. Фронт не должен по своему желанию запрашивать сущности по связям, как ему хочется

Закомичу нахрен ) Напишу, зачем столько одинаковых ключей )

вот самое то что нужно Да, GraphQL прячет резолверы ресурсов внутрь, делая бесполезными коды ошибок HTTP, глаголы HTTP, заголовки HTTP, используемые промежуточным ПО для кеширования и контроля работы с данными. Именно об этом я и говорю, GraphQL — это «ленивое» проектирование, которое удешевляет разработку на старте проекта, но удорожает на дальнейшей разработке и поддержке.

все так

да, и я определяю связи между сущностями. Фронт не должен по своему желанию запрашивать сущности по связям, как ему хочется

Почему нет?

Почему нет?

потому что это не его ума дело

модели и связи - это часть бэкендной бизнес-логики

потому что это не его ума дело

Так схему ты определяешь, то что ты ему разрешишь фетчить, то и будет

Так схему ты определяешь, то что ты ему разрешишь фетчить, то и будет

я ему разрешаю фетчить сущности через REST

Разницы никакой

ERROR: S client not available

большая

сущности != связи

Ты можешь условно говоря тот же гет отобразить на query

Ок, ты его использовал? Мне кажется ты не совсем понимаешь для чего это все

Только для возврата информации, исключительно запрошенной клиентом у серва. Если запросил 1 , то получил 1, а не кучу доп хвостов из базы и т.п. Я так понял.

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

Ты можешь условно говоря тот же гет отобразить на query

могу. Но это мне решать, а не фронту

Ок, ты его использовал? Мне кажется ты не совсем понимаешь для чего это все

понимаю, я читал плотно, как он работает

могу. Но это мне решать, а не фронту

Дык фронт не решает

Спеку делаешь ты, фронт решает только то, что можно взять по спеке

понимаю, я читал плотно, как он работает

Новодворскую напомнил

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

каким образом? наоборот же как раз. Я джойню на бэке и решаю, как это фронту отдавать

понимаю, я читал плотно, как он работает

Стойте стойте. Скажите только, вы же плотно читали, они там в дальнейшем так и не будут сокращать возврат 10к одинаковых ключей? Типа как я выше фоткал.

а он не должен хотеть сверх того, что я ему могу дать

Nikolay, вот это они там так и не решат?

Стойте стойте. Скажите только, вы же плотно читали, они там в дальнейшем так и не будут сокращать возврат 10к одинаковых ключей? Типа как я выше фоткал.

как опишешь - так и будет

Ааа, эта логика возврата одинаковых ключей, в сервере описывается? так получается?

а он не должен хотеть сверх того, что я ему могу дать

ещё раз, он и не будет хотеть сверх того, они работают только в рамках спеки

ещё раз, он и не будет хотеть сверх того, они работают только в рамках спеки

вот и пусть работают в рамках спеки реста

А разница ?)

А разница ?)

логика на бэке в разы проще

Ну эт спорно

На функциональных языках все довольно чисто выглядит

@sas1024 как у тебя там на гошечке? Чистый код?)

Ну эт спорно

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

когда у тебя есть набор хэндлеров с четко очерченной логикой и нормальной абстракцией - все это сразу становится ненужно

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

А рест не придётся ?)

А рест не придётся ?)

рест менее общий, поэтому не придется, да. Как написал хэндлеры - так и будет

Значит ты точно не понимаешь про что речь

понимаю, я писал много раз ресты

В graphql тоже самое, как ты написал хэндлер, так и будет

в том числе без привязки к конкретной базе