https://facebook.com/groups/graphql-kr logo
Join Slack
Powered by
안녕하세요. 혹시 node.js 에서 rest 의 경우 `next()` 를 통해 다음 미들...
# 질문
u
안녕하세요. 혹시 node.js 에서 rest 의 경우 
next()
를 통해 다음 미들웨어로 넘길지 말지를 결정하는데 gql에서는 
context
단에서 응답하고 
resolver
로 넘기지 않을 수 있나요? 현재는 `context`에서 문제가 있다면 `resolver`로 에러를 리턴하여 에러가 있다면 `resolver`에서 에러를 응답하는 방식입니다
h
음 그냥 throw 하셔도 되지 않나요?
u
@Hyeseong Kim context에서 throw 말씀이신가요?
h
context나 resolver요. 혹시 "에러를 리턴"하는 코드 예시가 있을까요
u
resolver 부분에서 ApolloError(authErr)를 리턴하는 부분입니다
h
바깥에 에러 핸들링 하는 미들웨어를 두고 거기서 스택 내에서 throw 된 에러 잡아서 적절히 처리해주면 다른 미들웨어나 리졸버에서 신경쓸 필요는 없을텐데용
허걱 저렇게 error 객체 리턴하면 다른 validation 에러로 대체당하지 않고 제대로 응답 errors에 넘어가나요?
t
이건 저도 좀 궁금하네요 ㅎㅎ
h
소스보러 가야겠다. 실제로 에러 포워딩 되면 지식 +1
graphql-tools의 makeExecutableSchema 쓰시는거죠?
u
넵
t
제 케이스는 Node.js 에서 클라이언트 스키마로 사용하는 경우가 있어서... context안에 있는 req, res를 못쓰긴해요. (Apollo server express 기준) 그래서 context creation 시점에 throw 하긴해요
혹시 context를 그냥 object literal 형태로 사용하시나요?
h
Express는 내장된 오류 핸들러와 함께 제공되며, 내장 오류 핸들러는 앱에서 발생할 수 있는 모든 오류를 처리합니다. 이러한 기본 오류 처리 미들웨어 함수는 미들웨어 함수 스택의 끝에 추가됩니다.
`next()`로 오류를 전달하지만 오류 핸들러에서 해당 오류를 처리하지 않는 경우, 기본 제공 오류 핸들러가 해당 오류를 처리하며, 해당 오류는 클라이언트에 스택 추적과 함께 기록됩니다. 스택 추적은 프로덕션 환경에 포함되어 있지 않습니다.
참고로 Express나 Koa 같은 애들은 기본 내장 핸들러가 이미 있어용
t
음 근데 resolver에서 throw 되면 자동으로 graphql이 잡아서 200 내려주지 않나요?
u
@Tony Won음 object literal 형태가 정확히 무엇인지 모르겠네요 ㅜㅠ
throw 되면
200이 아닌 다른 status로 가던것으로 기억이 나는데 예전이라 정확히는..
t
저는 nexus써서... nexus가 해주는걸수도 ㅋㅋ
u
일단 에러 핸들링하는 미들웨어를 더 확인해 봐야겠네요
t
context: {...} 요런식으로 쓰세요 아니면 context: async () => {...} 요런식으로 함수형태로 쓰세요??
h
근데 아마 apollo-server-express 같은데서 사용자 인증 구현하시려는 것 같은데 미들웨어는 똑같은 express 라서 그냥 res.end 해버리시면 리졸버까지 넘어갈일 없을거에용
u
@Tony Won 함수형태로 사용합니다
@Hyeseong Kim 넵 참고해보겠습니다
t
음 그러면 함수안에서 throw 하시면 되지 않나요??
u
일단 throw 해보고 판단해봐야겠네요
message has been deleted
throw 할 경우
bad_request로 status가 가네요
h
네 그게 맞습니다 ㅋㅋ
아 근데 상태코드는 바꿀 수 있으려나
ohh 1
리졸버에서 return error 를 하시면 transform 하다가 파싱 에러로 throw 해서 응답 errors에 엉뚱한 에러로 들어갈거같거든용
t
저도 이거 상태코드 바꾸는거 궁금해요 ㅎㅎ
저는 그냥 저대로 쓰고있습니다
h
근데 원래 400 맞나요
200 아니였나
t
Context creation failed는 400이에요
하도 쓰는 framework이 많아서 뭐가 400으로 주는건지는 모르겟네여 ㅋㅋㅋㅋ apollo server 겠죠?
h
apollo-server-express 기본 에러 핸들러를 보면 되겠군요 아마 최상위에 뭐 있겠네
👍 1
u
아직 gql입문인 제게는 어렵네요 ㅜㅠ
h
ㅋㅋㅋ GraphQL 보단 미들웨어 구현 디테일 문제같긴해요
미들웨어에서 Error throw 하실 때 그냥 쌩 에러 말고
이걸로 던지세요
statusCode는 여기 두면 됩니다
import { HttpQueryError } from 'apollo-server-core'; throw new HttpQueryError(401, "Auth failed");
아 아예 
throwHttpGraphQLError
라는 유틸이 있네요
u
오 지금 상황에 딱 맞는 에러인것 같네요
h
이건가
허허허허허허허.....
u
아 이부분이네요 여기서 400으로
빠지는것 같네요
h
잘 이해가 안되는군요.. 그래서 실제로 throwHttpGraphQLError 로 던져도 상태코드는 안바뀌는거죠?
u
throwHttpGraphQL가 import 안되네요..ㅜ
h
아하....;
dist에서 꺼내셔야 할듯
apollo-server-core/dist/runHttpQuery
아 근데 어쨋든 쓰라고 열어둔 API는 아니니 안쓰는게 맞는 것 같아요
상태코드는 그냥 시키는대로 쓰는걸로 ㅎㅎ;
사실 GraphQL에서는 RESTful 처럼 상태코드에 크게 의미를 부여하진 않아요
u
음.. 근데 클라이언트에서 200이랑 400 자체가 다르게 빠져서 200으로 줘야 될듯해요.. 일단 미들웨어에서 핸들링 가능한지 더 알아봐야겠네요
h
다르게 빠진다는건, GraphQL용 클라가 아니라 다른 http 클라이언트를 사용하시고 있나요?
u
음.. 그건 저도 잘 모르겠네요 물어봐야겠네요
Open in Slack
PreviousNext
Powered by