Это у самого графкуэля может быть массив ошибок, т.к. он дергает тьму резолверов. А у вас в логике может быть всего одна.

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

Всем привет.

Есть ли ограничения в данном чате? Добавляю интересующий вопрос- и пост удаляется.

Неактуально. Не прочёл инфу для новых пользователей.

/trust

Принято!

почему только одно?

количество ошибок в бизнес-логике может быть 0, 1 или несколько, это зависит от, хмм, бизнес-логики

ну, например, мутация создания пользователя, вы создаёте пользователя, это основное действие, а ещё вы создаёте для него проект и начисляете какие-нибудь бонусные баллы другому пользователю, то есть суммарно 3 действия, лишь 1 из них необходимое, любое другое может завершиться успехом или неудачей (если неудача - ну, ладно, попробуем отложить задачу и сделать позднее, а пока вернём ошибки)

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

Мы перемешиваем сейчас исключения в коде и ошибочные статусы в бизнес логике.

Исключение может быть одно на резолвер и никак иначе, поэтому error.

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

Я говорил про исключение, вы говорите про проблемы в ходе операции.

Я специально избегаю слово ошибка, т.к. слово одно, а природа у эттх ошибок разная.

Я не очень понял про исключения если честно. Думаю, мой вопрос не совсем про них.

Предположим, у вас есть GraphQL API Gateway/bff, который «торчит попой» наружу в Интернет и принимает запросы от SPA. Он является прокси для внутренних (микро)сервисов, которые находятся внутри безопасного периметра в нашем облаке, доступа из браузера напрямую к ним нет. Запрос создания пользователя обрабатывают несколько микросервисов. Один из них мог не ответить в заданный промежуток времени из-за сбоев сети, из-за исключений где-нибудь в коде из-за бага в новой версии или же из-за неких ограничений в бизнес-логике. То есть мутация вызывает некую сагу, которая что-то там делает с внутренними микросервисами, это уже за пределами зоны ответственности GraphQL сервера, а когда она что-то там сделала, есть понимание статуса выполненной операции. Допустим, это Success, пользователя мы зарегистрировали, но некие дополнительные операции завершились с ошибкой по тем или иным причинам и мы можем захотеть сообщить об этом клиенту (js-клиенту, что нужно ещё раз запросить создание проекта) и/или, возможно, пользователю (вывести уведомление о технических неполадках и попросить зайти позднее).

Так вот, вопрос был про то, что если у нас есть некий набор ошибок, которые мы хотим сообщить клиенту на js и/или пользователю клиента, как это лучше сделать… Все они сериализованы в понятном клиенту виде, должны ли они быть собраны вместе в некий список ошибок или же под каждым полем свои (если есть)

С Apollo Client мы же получаем некий аналог state manager’а и можем обойтись без него. Статья кажется слегка устаревшей

А если произошла ошибка регистрации пользователя, как клиент различит что произошла фатальная ошибка?

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

В вашем примере, когда регистрация прошла, а два других микросервиса неотработали - все равно считается выполненной. И иметь статус success, либо partial_success, но она выполнилась. Единственно что рядом можно подложить это warnings.

Т.е. рекомендую явно поле error в пейлоаде мутации отдавать за исключением резолвера, если это поле не пустое то точно операция провалилась.

А вот всякие внутренние "неважные неприятности" уже ложить в поле, к примеру, warnings.

В любом случае, поля errors с массивом ошибок в пейлоаде мутации вообще быть не должно. В противном случае либо куча холивара всегда будете поднимать, либо надо обкладываться документацией и всег всегда в нее отправлять.

Она не устаревшая она идиотская полностью. Человек взял комбаин в виде аполло и рассуждает о том что данные все равно надо в стейт менеджер пихать, а аполло весит много 🤦‍♂️

Если тебе религия не позволяет работать в парадигме автоматического кеша и графкл ты хочешь использовать только для удобных запросов есть graphql-request весом в пять кб со всем.

Вот в самом первом примере я запрашиваю данные по пользователю и по проектам пользователя. Если получилось получить данные по пользователю (уже означает, что успех), но не получилось получить данные по проектам пользователя, как лучше всего вывести информацию «Вася, создай проект вручную, автоматически не получилось, у нас лапки»? Внутри projects положить описание ошибки с текстом для пользователя? Или придумать сразу под data некий раздел для такого? Или в errors?

Что случилось с хабром? Когда он успел похорошеть???

Я давно не видел, чтоб в комментах шла адекватная дискуссия, без поливания друг друга.

Думаю это временное явление