Это надо ругать тим мейтов, и строить строгие правила внутри команды

там где с ними будут проблемы

да, я уже понял что с gql нужны какие-то чёткие правила по ведению кверей

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

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

всем привет. хочу уточнить один вопрос, по которому уже получал частичный ответ. я использую api для странички с пагинацией и беда в том, что в этом api нет функции возврата общего количества значений. то есть я не знаю, когда останавливать пагинацию. Я вижу 2 пути решения:1)если пользователь нажимаема на кнопку получения следующей порции данных и их нет, то он переходит на страницу на котором написано что данных нет. 2) делать запрос к следующей порции данных при получении текущей для определения конца данных.(но это же очень затратный метод.особенно если будет большое количество данных и страниц). 100 переходов - 200 запросов. Как бы вы поступили?

Сделать infinite scroll?

Мейби

Давайте это обсудим, коллеги

оба говно

Ну я в 2013 говорил, что REST говно, видать, чтоб понять, что GQL говно, вам понадобится еще лет 5-7

Согласен!
Только чистые sql запросы из темплейтов на сервере в базу

кому нужен graphql, если можно просто на сервере делать eval присылаемого кода?

Граф хуель нужен, чтобы ебать мозги бэкендерам

Зачем чушь всякую нести здесь? Нормальная технология.

кокой вы серьезный. наверное, бэкендер? 🌚

Нет я не серьёзный, но рест апи намного удобней реализовано в плане архитектуры сервера

Самый ад - это схемы графкл

так вы-то понятное дело, а вот @Anyany00 сразу видно системс архитект :з

херовина типа TypeGraphQL немного облегчает боль, но ничто не убирает ее до конца