Комментарии 14
Насколько удобно работать с ошибками? Применялись ли какие-то дополнительные библиотеки на сервере или на клиенте для работы с ошибками? Ведь в стандартном случае graphql выдает ошибки аналогичные stacktrace.
Я хочу прояснить что я имею в виду. В REST я могу например выдать ошибку в которой передать например message которое будет выдано клиенту в виде всплывающего окна. Либо передать поле status c кодом ошибки в котором клиент по зараннее заданному списков кодов ошибки выберет вариант взаимодействия с пользователем. Или если это ошибка валидации входных данных, то в REST я могу выдать список полей с описанием ошибок во входных данных. Всего этого нет в стандартном graphql который в случае ошибки выдает текст, генерацией которого мы не можем управлять.
Ошибки, валидацю можно и нужно передавать в привычном виде. То что выдаётся как стектрейс это только ошибка с синтаксисом запроса или же проблема типа.
Вы имеете в виду что каждый тип выходного объекта должен включать в себя поле error/errors? А сам объект возвращать в поле data/payload и т.п.?
У меня в основном к этой идее идут мысли. Но это сразу все усложняет.
Плюс если правильный ответ это как правило один тип. А ошибок может быть несколько типов. Как минимум ошибка с зараннее оговоренным статусом, ошибка в которой передается необрабатываемый на клиенте текст сообщения, и ошибка валидации входных параметров.
Да. Но для запросов вам никаких ошибок или валидаций делать не надо. Потому это все усложнение будет касаться только мутаций. А мутация может возвращать результат в виде составного объекта. Там будет объект и какая-то механика для ошибок.
Подход стандартный в том сервере что используем мы django-graphene и не вызвал каких-то проблем привыкания.
app.use('/api', auth.validateTokenMiddleware, graphqlHTTP((req, res) => {
___ return {
___ ___ schema: apiModulesManager.gqlSchema,
___ ___ pretty: true,
___ ___ context: { req, res, dataloaders: buildDataloaders() },
___ ___ formatError
___ };
}));
function formatError(err) {
___ log.error(err);
___ return {
___ ___ // standard fields:
___ ___ message: err.message,
___ ___ path: err.path,
___ ___ locations: err.locations,
___ ___ // extended fields:
___ ___ code: err.code || 'not classified error',
___ ___ localizedMessage: err.locMessage || `not localized: ${err.message}`
___ };
}
Для того, чтобы всё это работало, в нужных местах кидаются исключения с необходимыми полями.
P.S. Отступы в коде были безжалостно пожраны хабром. Пришлось извращаться с "___ " :(
P.P.S. Естественно, речь идёт об ошибках, полученных во время выполнения функциональной части запроса, а не при парсинге текста запроса (то бишь синтаксических ошибках в тексте запроса).
Рекомендую к прочтению https://github.com/nodkz/conf-talks. Идея в том, что надо использовать свои типы-ошибки для возврата бизнесовых ошибок через Union. Стандартный errors использовать только для технических ошибок (500-ые)
Из статьи неясна мотивация перехода на GraphQL, поподробнее бы это осветить.
Neveil вот, например, статья, которая могла бы послужить мотивацией: habr.com/ru/post/470097
Молодец!
Почему какие-то "спринты" вообще рассматриваются как фактор?
Как мы переводили легаси проект на GraphQL