[GraphQL/review] DEVIEW2023: GraphQL 잘 쓰고 계신가요?

 

https://tv.naver.com/v/33860107

NAVER D2

 

DEVIEW 2023의 GraphQL 잘 쓰고 계신가요? 영상을 시청했다.

요즘들어 기초 탄탄에 유독 꽂혀있는 나에게 금 같은 영상이었다.

 

해당 세미나는 강의자가 실무에서 겪었던 문제들을 GraphQL의 다양한 기능을 활용해 해결하는 흐름으로 진행된다.

강의를 들으며 '이런 기능이 있구나'에서 그치는게 아니라, 사고를 확장할 수 있는 양질의 강의라고 느꼈다.

 

나는 특히 interface를 활용한 에러 핸들링 부분이 인상 깊었다.

 

몇 개월 전 실무를 진행하며 graphql의 에러 핸들링 방법에 대해 리서치한 적이 있다.

graphql에서는 에러를 일반적인 http 상태코드로 처리해주지 않고 graphql 만의 문자열 error code로 처리 해준다.

(http 상태코드는 graphql이 정한 규칙에 따라서 정해진다. http status와 기준이 매우 다르다.)

 

리서치 당시, 왜 문자열 에러 코드를 쓰지? 라는 생각이 제일 먼저 들었다.

http 상태 코드야 이미 표준이 정해져 있기 때문에 클라이언트에서도 여러 에러 상황에서의 대처가 가능하다.

하지만 graphql만의 에러 코드는 공식으로 정해진 error code도 몇 개 없고, 커스텀 기능이 있긴 하지만, 이를 활용하려면 클라이언트와 서버가 사전에 무조건 합의가 되어야 한다고 생각했다. 서버가 보내는 에러를 클라이언트가 모르면 처리할 수 없으니 말이다.

 

발표자는 이를 해결하기 위해 interface를 활용하여 에러 핸들링을 했다.

interface로 BaseError라는 type을 만들고, BaseError를 활용하여 여러 커스텀에러 type들을 제작하는 방식이다.

그래서 클라이언트는 서버면에서 새로운 에러가 만들어지더라도 BaseError에 대한 처리가 되어있으면, 사전에 협의되지 않은 에러에 대해서도 대응이 가능하다.

 

#서버
interface BaseError {
  msg: String!
}

type DuplicateError implements BaseError {
  msg: String!
}

type wordError implements BaseError {
  msg: String!
  words: [String!]!
}

 

#클라이언트

query {
  checkNickName(nickName: "자라나라개발머리") {
    __typename
    ...on NickNameSucceed {
      nickName
    }
    ...on DuplicateError {
      isDuplicated
    }
    ...on wordError {
      words
    }
    ...on BaseError {
      msg
    }
  }
}

 

graphql에서는 이런식으로 interface를 활용할 수 있구나, 이렇게 하면 에러 커스텀을 얼마든지 할 수 있겠는데? 라는 생각이 들었다.

그나마 Scalar, enum에 대해선 알고 활용하면서 지내고 있었는데, interface는 활용까지는 못했었다.

역시 아는 것이 힘.. 더욱 열심히 탐구해야겠다는 생각을 했다. 이번 기회로 graphql에 대한 지식이 한 단계 깊어진 느낌이다.

schema 구성 시에 graphql의 기능을 활용해 좀 더 클라이언트 친화적으로 스키마를 구성하고픈 욕심이 생겼다.

 

리뷰 끝!