AS
По всякому пытался
Size: a a a
2019 June 14
AS
и родными средствами телеграма и внешней ссылкой. Скидывает
P@
Приветствую, Павел!
Во-первых, спасибо за видеолекции и статьи! Много нужного извлек оттуда.
И вроде разработка на графе идет нормально. Но вот обработка ошибок - это боль страшная.
И если введение union-типов для обозначения "проблем" решает одну часть боли. И на клиенте вроде удобно, и в документации отображается. Все хорошо.
Но вот другой момент, никак не дает покоя. А именно, ответы графа (ошибки), в случае несоответствия схемы присланной клиентом и той, что на сервере.
Например, отсутствие обязательного поля или неправильный тип данных поля. Это ж как бы одна из килер-фич графа. Проверять еще до резолверов присланные данные и реагировать. Но реакция странная)
Граф оформляет проблему в ошибке тупо в виде текстового описания. Например, забыли обязательное поле "name", получи - 'Field "login" argument "name" of type "String!" is required but not provided.'
И как тут на клиенте понимать, что произошло, на уровне логики, непонятно. Не парсить же этот текст)
И пока решение такое, убрал в схеме эти восклицательные знаки почти везде и проверяю обязательность полей на уровне резолверов, стандартными средствами валидации ларавеля. Оттуда уже прилетают нормальные ошибки валидации, которые более-менее научил клиент распознавать и решать что с ними делать. Но в этом случае пропадает эта фишка графа. И зачем тогда она нужна)
Может есть какие мысли на этот счет? Думаю не один я тут с такой заморочкой вожусь)
Во-первых, спасибо за видеолекции и статьи! Много нужного извлек оттуда.
И вроде разработка на графе идет нормально. Но вот обработка ошибок - это боль страшная.
И если введение union-типов для обозначения "проблем" решает одну часть боли. И на клиенте вроде удобно, и в документации отображается. Все хорошо.
Но вот другой момент, никак не дает покоя. А именно, ответы графа (ошибки), в случае несоответствия схемы присланной клиентом и той, что на сервере.
Например, отсутствие обязательного поля или неправильный тип данных поля. Это ж как бы одна из килер-фич графа. Проверять еще до резолверов присланные данные и реагировать. Но реакция странная)
Граф оформляет проблему в ошибке тупо в виде текстового описания. Например, забыли обязательное поле "name", получи - 'Field "login" argument "name" of type "String!" is required but not provided.'
И как тут на клиенте понимать, что произошло, на уровне логики, непонятно. Не парсить же этот текст)
И пока решение такое, убрал в схеме эти восклицательные знаки почти везде и проверяю обязательность полей на уровне резолверов, стандартными средствами валидации ларавеля. Оттуда уже прилетают нормальные ошибки валидации, которые более-менее научил клиент распознавать и решать что с ними делать. Но в этом случае пропадает эта фишка графа. И зачем тогда она нужна)
Может есть какие мысли на этот счет? Думаю не один я тут с такой заморочкой вожусь)
Все запросы на клиенте должны быть статичными и не составляться динамически. Если запросы статичные, то их можно проверять на этапе написания кода, всякими линтерами и компиляторами. Можно генерировать тайп-дефинишены для Тайпскрипта или Флоу (если клиент на JS). Т.е. то что у вас происходит, это “доведение греха до рантайма”. И часто это связано с тем что запросы составляются динамически на клиенте – в таком случае никаких тайпчеков не сделать. И надо мучиться с парсингом ошибок.
KN
Ну описанная проблема, кажется не проблема
KN
Если ломается bc, то надо создавать новое поле
KN
С новым резолвером
KN
Т.е. Отсутствие bc - это не фича graphql, а фича прямых рук)
KN
Просто с gql проще
AS
Это все понятно. Но смысл таких ответов графа в чем тогда? Тупо для человека? Распознавания им проблемы. На уровне кода же не распознаешь, что произошло конкретно. Тип неправильный или поля не хватает.
KN
Можно на сервере добавить экстенш
KN
Вон, у тебя там категория, например
AS
Понятно, что тот кто пишет изначально и сервер и клиент все это учтет. А другой чел, кто будет писать свой клиент. Будет получать эти же описания.
KN
И будет видеть категории, да
KN
graphql - ошибка запроса, кажется
AS
Я вот и думал, что можно как-то переоформить эти ответы на стороне сервера в понятные ошибки валидации. И на клиенте тогда не будет проблем с распознаванием.
AS
graphql - ошибка запроса, кажется
да, это так. Но это дает обобщеное понятие ошибки. но никак не указывает на конкретную проблему.
KN
Всё расширение ответов Делается с помощью экстеншенов
KN
Блин, с телефона сложно печатать без ошибок)
U
Это все понятно. Но смысл таких ответов графа в чем тогда? Тупо для человека? Распознавания им проблемы. На уровне кода же не распознаешь, что произошло конкретно. Тип неправильный или поля не хватает.
На ошибки уровня graphql сервера нужно превентивно проверять на этапе сборки/компиляции. А для пользовательских ошибок нужно написать свой обработчик ошибок (гуглить graphql custom error) на сервере, и потом отдавать, например, код ошибки. Я так делал. Вот пример:
Кастомная ошибка
Пример её вызова
Пример обработки на сервере
Кастомная ошибка
Пример её вызова
Пример обработки на сервере
AS
Uxname, спасибо, посмотрю!