Привет. Пришёл из мира бекенда. Имею вопрос формата "делают ли так". Есть мутация

(условно - регистрация), что в бекенде идёт в несколько upstream API (два). И ошибка полученная впоследствии вызова второго upstream API есть некритичной.
Клиентской стороне, тем не менее, очень полезно знать что "второй шаг" не выполнен успешно и очень полезно знать детали "почему".

Для выдачи результата мутации (условно - auth token, user id) достаточно данных, что доступны после вызова первого upstream API.

Варианты решения:

1. Просто заглушить проблему вызова второго - легко. Но не решается вопрос выдачи деталей ошибки
2. Попытатся сделать "свой тип" для ошибки вызова второго upstream и возвращать как часть success result - почти легко. Минусы - похоже понадобится почти повторять GQL error структуру.
3. Union type: совсем успех, почти успех (с ошибкой - при проблемах вызова второго upstream). Минусы - выглядит неудобным к расширению - сейчас сломаются все клиенты т. к. это BC break (либо изворачиватся с расширением базового типа как-то?).
4. Выбрасывать ошибку конкретного вида с добавленными в .extensions данных что есть частью success result - auth token, user id и научить клиенты работать с этой ошибкой. Минусы - неявная связь между данными в успешном результате и в ошибке - нужно помнить что нужно в ошибку пытатся докидывать тоже новые данные, что могут появлятся в success result type.

Склоняюсь к второму варианту.
Вопросы:
1. есть ли второй вариант распространённой практикой?
2. возможно я не вижу другие минусы второго варианта?
3. возможно есть существенные плюсы других вариантов или другие варианты?

——

PS: разделять мутацию на две и говорить клиентской стороне всегда пользоватся в нужном порядке - максимально не хочется.

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

Максимально не хочется использовать этот вариант по причине того, чтобы для success flow (коих большинство) оставить простой и быстрый процесс. Быстрый - потому что бекенд имеет данные для вызова второго upstream и не требуется network roundtrip от клиента. Простой - при успехе пользователь уже полноценно может пользоватся сервисом (все формальности по регистрации завершены). А батчем вызвать не получится нормально, т. к. результат вызова первой операции нужен второй операции.

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

Если это про бекенд - он не на JS и я не видел поддержку таких фич. Если это про клиент - это network roundtrip от клиента.

Дык я про фронтенд и пишу, вебморда на чём? Rx можно встроить и симитировать батч по сути, с сохранением цепочки, для примера

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