Так вот, не противоречит ли спецификации GraphQL изменения ключа в ответе на мутацию:
Например, есть mutation createUser, и при вызове мутации, в ответе возвращается {"data": {"createUser": ...}}
Можно ли сделать так, чтобы возвращалось что-то типа {"data": {"userThatWasCreated": ...}} и это не нарушало спецификацию GraphQL ?

Вы сами можете именовать мутацию же, в чем трабла то?) Как и квери можете комбинировать и именовать

Кеш все равно по typename составляется

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

Вы можете так делать, это ничего не нарушает

А случайно не знаете, может ли такое сломать какие-нибудь grahpql-клиенты?

Нет, так как кеширование по __typename как я говорил выше

Я тоже обожаю авангард в искусстве :) Хорошие картинки

Понял, спасибо

Можно алиасы использовать

mutation CreateUser {
  userThatWasCreated : createUser { ... }
}

О, да, спасибо! Как раз то что нужно было

тут обсуждалась тема с ошибками, я наткнулся в документации Apollo на ссылку на видео https://www.youtube.com/watch?v=RDNTP66oY2o

из интересного там - https://youtu.be/RDNTP66oY2o?t=1379 (таймкод с запросом)

как вам идея называть вместо profileImage, например, profileImageResult? и так по всем связям

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

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

Как у меня:
- в 99% кверей ошибка вылетает на самом верхнем уровне в errors
- в 99% мутация в MutationResult я ложу поля error и result.

Юнионы избегаю по максимому везде, т.к. на фронте с ними не шибко удобно и прозрачно работать.

Я чувствую, мне хочется ещё изучить популярные сервисы типа Hasura, как там сделано это…

Если я правильно понял её подход, то она ожидает проверку типа от фронтендера

В её видео или в другом на том же канале было про опциональные поля. То есть лучше чтобы фронтендеры заморочились с проверками чтобы при необходимости можно было бы сломать API контракт (точнее, схему) :-)

Мне в целом юнионы симпатичны из-за своего рода типизации

По идее запросы нужны чтобы обновлять кеш Apollo Client’а, а не для того чтобы результат как-то парсить вручную, то есть они не должны сильно мешать…