개요

GraphQL은 보통 자료형의 field를 통해 자료형 사이의 관계를 표현하게 된다.

책 {
  페이지 {
    종이 {
      재질 {
        ...
      }
    }
  }
}

아직 쪼물딱거리는 단계이긴 한데, 자료형들을 정리하는 규칙 같은걸 한번 정의해 보는게 이 글의 목적.

규칙

1. 가능하면 자료형에 직접 접근할 방법을 마련하자

이를테면 ‘책’ 객체의 자식 요소로 ‘페이지’에 접근할 수 있지만, 가능하면 ‘페이지’에 직접 접근할 방법도 있으면 좋지 않을까 싶다는 것.

2. 커서 기반 Pagination을 한다면, 커서를 가지고 Get할 방법도 있어야 할 것

이를테면 내가 어디까지 읽었는지에 해당하는 커서 값을 저장했다가 나중에 다시 돌아왔을 때, Cursor Connections를 써서 예전/다음 값들을 가져오는 것은 좋은데, 막상 현재 커서에 해당하는 값을 가져올 방법이 없으면 곤란하지 않겠냐는 것이다.

3. Pagination이 subset 단위로 일어난다면, 부모/자식 관계를 강제하는 편이 좋지 않을까?

이를테면 ‘페이지’ 객체를 pagination할 때 무조건 ‘책’ 내에서만 pagination이 일어나게 되고, 여러 개의 다른 책이 존재할 수 있는 상황이라고 한다면, 일단 ‘책’을 가져온 다음에 거기 안에서 커서 기반 query들을 제공하는 편이 더 맞지 않겠냐는 것이다.

이게 1번이랑 충돌하고 있긴 한데 - 자료형에 직접 접근한다는 것은 부모 객체 없이 접근한다는 뜻이기 때문 - 그냥 둘 다 구현해 보고 나중에 정리해 보자.

4. 순전히 자식 객체를 접근하려고 부모 객체를 불러오는 일은 피하고 싶다

이를테면 난 ‘페이지’ 객체 목록을 접근하고 싶을 뿐인데, 이게 3번 때문에 ‘책’ 객체를 가져와야 하고 단지 그것 때문에 제목, 저자명 등 ‘책’에 포함된 다른 요소를 읽어들일 필요는 없지 않겠냐는 것이다. 이것은 Resolver를 잘 짜면 자연스럽게 해결될 것 같긴 한데, 어쨌든 핵심은 Pagination만을 위한 필수 요소만을 저장할 수 있는 가짜 ‘책’ 객체를 지원할 필요가 있다는 것.

5. 그렇다고 다단계 부모/자식 관계를 강제하고 싶진 않은데…

이를테면 책 -> 페이지 -> 종이 식으로 관계가 정해져 있다고 하더라도, 단순히 종이 객체 접근만을 위해서라면 ‘페이지’만 알면 됐지 ‘책’까지 알아야만 하는건 뭔가 이상하지 않나? 싶다.

결론

일단 이정도로 정리해놓고 구현을 해 보고, 앞으로도 계속 추가하거나 정리해 볼 생각.