Вы запрашиваете данные через квери или все-таки выполняете мутацию? Тяжело дать совет в такой ситуации.

Если мы продолжаем говорить про мутацию, то я бы просто в пейлоаде мутации, возвращал поле projectId: 23232 или hasProject: true. И уже на клиенте в зависимости от значения рисовал, то что надо.

Передайте клиенту более просто состояние, никто на клиенте не любит разбираться с ошибками, которые вроде бы и не ошибки.

В любом случае, вы как угодно можете договориться с фронтами. Cамое главное в ответе мутации просто не используйте поле c именем errors. Error, warning, problem, warnings - пожалуйста.

на данный момент я пытаюсь проанализировать список возможных решений и найти лучшие практики чтобы потом создать некий coding style для себя и коллег)

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

то есть эти запросы они не реальные, они просто из головы для примера (точнее, с тестового стенда), просто хочется выработать некий единый подход и везде ему следовать (и рекомендовать своей команде делать так же)

В тему к статье, я наоборот буду защищать Аполло для энтерпрайза. Заодно расскажу зачем там все-таки используется AST запроса, а не текст запроса. И происходит "ужасный" оверхеад в рантайме. Который по сути на флеймчартах даже разглядеть невозможно, хоть у вас пусть будет 100 запросов.

## Название доклада

Докручиваем ApolloClient до энтерпрайзной разработки

### Место действия

Активно развивающееся поселение фронтендеров уверовавшее в ApolloClient 3. Жители поселения обычно немногословны и используют черную магию кодогенерации. Для защиты своего быта от набегов варваров активно используют TypeScript и Eslint. Основной промысел жителей – создание SPA приложений.

### Мораль

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

### Акты

- Вступление
 - пару слов про героев пьесы
   - GraphQL
   - ApolloClient 3
   - GraphQL Code Generator
   - TypeScript и Eslint
- Знакомство с болванкой SPA приложения
- Live coding
 - Query
 - Mutation
 - Subscription
- Борьба со Злодеями
 - Фронтендеры вносящие хаос в код и усложняющие ревью кода
 - Бэкендеры ломающие API

### Главные действующие лица:

- GraphQL – язык запросов, для получения данных с бэкенда
- ApolloClient 3 – стейт-менеджер для хранения и обновления данных полученных через GraphQL
- GraphQL Code Generator – утилита для генерации хуков и тайп дефинишенов из `.graphql`-файлов
- TypeScript – статический типизированный JavaScript, дающий возможность проводить статический анализ кода приложения
- Eslint – линтер, позволяющий проверять код на соответствие принятого code style в проекте. Плюс плагины prettier, @graphql-eslint/eslint-plugin.

### Второстепенные роли:

- VSCode – бесплатный и навернутый редактор кода с плагином graphql.vscode-graphql
- NextJS – фреймворк для React, который решает головную боль роутингом, билдом приложения и его рантаймом
- Ant.design – живой UI-kit с приятными компонентами

### Главные антагонисты:

- Бэкендеры любящие часто менять API
- Фронтендеры любящие грязный код (например табы вместо пробелов)
- Boilerplate-код – детская травма полученная от Redux
- Развесистый Data Domain с кучей связей

-------

👉 https://2021.404fest.ru/?sessionId=255551https://2021.404fest.ru/?sessionId=255551

Промокод на 2000₽: 11SPEAKERFRIENDS

Онлйан трансляции не будет. Мероприятие проводится офлайн (вживую) в Самаре. Ждут 3000 человек.

-------

Потом этот доклад 2-5 ноября буду на HolyJS вести

Я года 3 назад составлял список таких правил. Они не шибко поменялись с тех времен. Вот как раз ссылка на error в мутациях
https://github.com/nodkz/conf-talks/tree/master/articles/graphql/schema-design#rule-6.6.4

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

спасибо, да, я согласен)

если честно, то мне тут не очень нравится, что используется некий общий тип и для ошибки и для успеха и получается, что может быть сразу всё, мб стоило бы отделить ошибку от успеха? или на это были некие причины?

то есть почему бы вместо это не возвращать что-то одно? Post | ErrorInterface

я где-то в англоязычном блоге видел статью на эту тему (мб эту https://graphqlme.com/2018/03/17/i-thought-of-a-better-way-to-handle-errors/)

мне там нравится комментарий Джона на эту тему:

I prefer the union approach.

In my mind, it’s very much like raising (and catching) a specific exception. By pre-declaring your exception conditions as first-class response types, it helps reinforce the API’s contract.

The other approach – in which a call to createUser might result in errors – is incongruent with how that response should look. If I call a method and it fails, it does not give me the type I asked for (plus errors) — it should just return the type of error that best represent what went wrong.

Хотите усложнить жизнь фронтендерам - пожалуйста. На фронте с юнионами не очень работается и писать запросы сложнее - надо знать типы для написания фрагментов.

Все должно быть тупо просто и единообразно. К примеру  сам графкуэль на верхнем уровне возвращает data и errors в разных полях. И вам того же советую.

меня немного смущает, что нет единого популярного общепринятого в западном мире стандарта на эту тему, например, в Apollo Server можно сделать вот так: https://www.apollographql.com/docs/apollo-server/data/errors/#throwing-errors и тогда будут какие-то свои кастомные ошибки в errors

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

(то есть мне в целом нравится, что они разрешают что-то кастомное засунуть в errors, но мне не нравится, что они этот вариант показывают в качестве единственного и ссылка в меню называется Error handling, что подразумевает не столько ошибки для разработчика, сколько ошибки от бекенда фронтенду)

Скорее это связанно с тем что есть некий стандарт graphql. Лексемы, разбор запросов и приведение к типам. Но в этом «стандарте» нет ошибок. Поэтому и каждый делает свой велосипед. Но вариация с data & errors наиболее правильная. Даже в мире реста дурной тон, когда у тебя возвращается ошибка в месте где должны быть данные.

например, в документации к Ariadne (реализация GraphQL-сервера на Python'е, примечательная тем, что делает это по принципу schema-first) критикуется такой подход: https://ariadnegraphql.org/docs/error-messaging