[ApolloClient] errorPolicy

참고문헌:

www.daleseo.com/graphql-apollo-server-errors/

www.apollographql.com/blog/full-stack-error-handling-with-graphql-apollo-5c12da407210/

Full Stack Error Handling with GraphQL and Apollo 🚀

 

<ApolloClient의 에러>

 

ApolloClient에서 데이터 에러를 받는 방식에 대한 결정

즉, 서버에서 받는 에러를 어디까지 보여줄 것인지에 대한 결정이다

 

 

<Apollo-link-error를 통한 top-level 에러핸들링과 한계>

 

공식문서에서는 apollo-link를 통한 에러 핸들링을 추천하고 있다.

각 에러 케이스에 대해 정의하고, console로 세부내용을 받아볼 수 있다.

그러나 server에서 발생하는 에러는 client에서 직접 파악하고 처리해야 할 케이스가 많다.

 

예컨데 토큰 만료 사례의 경우, 단순히 Link에서 에러를 처리하면 안된다.

이러한 케이스에는 client에서 에러 사항을 확인할 수 있어야 한다.

따라서 Apollo-link를 통한 에러 핸들링보다 코드레벨에서 직접 로직으로 에러를 핸들링하는 것이 더 다양한 케이스에 대한 대응이 가능해보인다.

 

 

<errorPolicy를 통한 에러 핸들링>

 

클라이언트에서 발생하는 에러는 대부분 클라이언트에서 처리하면 된다.

예컨데 쿼리의 variable이 잘못되었다든가 하는 케이스는 보통 클라이언트에서 잡아내서 처리한다. 

 

그러나 server에서 발생하는 에러는 세부 핸들링 로직이 필요하다.

 

serer에러는 크게 graphQLErrors와 networkError로 나뉜다

graphQLErrors는 리졸버의 로직 처리 도중 에러가 발생한 것이지만

networkError는 아예 리졸버에 접근하지 못한 경우를 말한다.

 

위의 예시는 대표적인 graphQLErrors 케이스인 partial failure가 일어난 케이스이다.

리졸버 로직 처리 과정에서 User타입에 해당하는 데이터는 가져오지 못하는 상황이 발생했다.

user의 email을 가져오는 로직은 문제가 없었으나, id를 가져오는 로직에서 에러가 발생한 것이다.

이러한 경우에는 fetch된 부분적인 데이터와 발생한 에러를 모두 반환한다. 

 

이러한 케이스는 쿼리 전달시 errorPolicy를 설정해 해결할 수 있다.

사용법은 특정 쿼리(useQuery,useLazyQuery)나 뮤테이션(useMutation)에 대해 정책을 설정해주는 방식이다

옵션 3가지 중 하나를 선택할 수 있고, none이 디폴트이다

 

각각의 옵션에 대한 설명은 다음과 같다

 

- none: partial failure에 대해 데이터를 받지 않는다.

- ignore: 데이터가 있다면 무조건 에러 없이 데이터를 전달한다.(위의 예시에서 에러가 발생하지 않는다)

- all: partial failure에 대해 에러를 리턴한다.

 

보통은 최상단에서 ApolloClient 객체를 생성할때, 쿼리와 뮤테이션 별로 전체 errorPolicy를 설정해주면 협업하기 편하다.

 

 

 

<또 다른 대책>

 

아예 리졸버 타입 설정시 필요한 Error타입을 선언하게 함께 리턴하는 방식이다

이건 다음에 다시 포스팅해야겠다