안녕하세요 현재는 apollo client - prisma 조합으로 개발중인데 Pagination 구현 관련해서, 클라이언트에서 relay를 사용하지 않는다고 하더라도 백엔드에서 Connection 모델을 구현했을때 어떤 이점이 있을까요?

그럼 지금은 limit + offset으로 하고계신가요??

훔. Relay 사용과 무관하게 커서 기반 페이지네이션의 이점을 누릴 수 있겠네요

아직은 구현 전 단계인데요~ 우선 이런 Pagination UI 를 지원해야해서 limit & offset 기반을 생각하다가 Relay compliant schema 로도 가능할까 싶어서 찾던 중에 누가 이 글을 알려주면서 가능하다고 하기에 알아보려던 참인데요 https://artsy.github.io/blog/2020/01/21/graphql-relay-windowed-pagination/ 우선은 어떤 이점이 있을까 고민해본후에 진행하려던 참이었습니다

저 글은 effortless하다면서 굉장히 effort가 드네요;; ㅋㅋㅋ

일단 제일 걸렸던 점은 이 방식은 totalCount를 어떤 식으로든 줘야하는데 저희만의 구조를 따로 정의하느냐 아니면 relay 표준을 따르느냐(totalCount 같은건 다 어떻게 주라고 되있더라고요) 고민이 좀 되었어요

페이지 넘버 기반으로 뷰를 보여주셔야한다면 굳이 Connection 해야하나 싶기는하네요. 커서 기반이 성능은 더 좋은거로 알고있어요. 근데 아이템 갯수가 적다면 큰 이점은 없을거같아요

그렇군요 저희가 추후에 혹시나 relay로 마이그레이션 하기 쉬울 수 있다는 것 빼곤 없겠군요

totalCount 만 어떻게 전달할 수 있다면 페이지 넘버 기반으로도 쓸 수 있으니 … 저였다면 어떻게 의견이 바뀔지 모르니 디자인이 개선될 지 모르니 그냥 커넥션으로 한다 (+ 알잘딱으로 totalCount 넣어준다) 로 할 것 같습니다

저희도 외부 공개 API 중에서 limit & offset (정확히는 페이지 번호) 로 제공되는 API가 있는데요

두 분 다 의견 감사드립니다!! 다양한 의견을 들으니 좋네요 ㅎㅎ

ㅎㅎ 첫 질문 감사합니다~

데이터셋이 좀 커지면 커서기반이여야 디비가 스트레스를 덜받아용

답변 감사드립니다 ^^ 네 저도 커서기반의 성능이점을 어필하면서 회사분들과 상의를 했었는데 페이지 넘버 기반이 꼭 필요하다고 하셔서 어쩔 수 없이 이렇게 가게 되었네요 딴 얘기지만 Apollo Client 3 이 좀 불안정하다고 한달전까지 계속 얘기를 들었었는데(주로 Reactiflux 채널 평판이긴 합니다) 혹시 사용하고 계시다면 불편한 점은 없으신가요? 2.6 대비해서 기능추가도 딱히 없다고 들었었거든요

내부적인 구조 개선 위주로 많이 일어났고, 기능도 꽤 바뀌었죠 (Custom resolver -> Reactive variables 이라던가, 캐시 폴리시 기반 캐시 제어 등)

😭😭 일단 마이그레이션은 시간날때 하긴 해야겠네요 urql 도 많이 쓰더라고요