1. 그레프 디자인할때 implementation details 절대로 밖으로 내보내지 마라

- 예를들어 M-to-M 관계 성립할때 필요한 테이블을 그래프로 내보내면 그 자채가 그레프 복잡함 증폭시킬뿐만 아니라 나중에 breaking change 되기 쉽상

- 10개 이상의 데이터 돌려보내는 그레프는 무조건 pagination


2. 레이트리밋

- 레스트에서 쓰던 레이트리밋을 그대로 그레프에 전목시키면 원래 레스트로 하나하나만 쏘던 요청을 그래프로 한방에 쏠수있는데 레스트에서의 레이트 리밋 자채가 그래프에선 말이안됨

- 그레프 복잡함의 따라 포인트로 운영되는 레이트리밋으로 가는게 나을것임 (근데 이걸 노드 같은거로 처리하면 5T 데일리 요청 정도 처리할시에 엄청난 비효율성을 보게될것임) 러스트 사용 해서 알고리즘 작성 추천


3. dataloader

- 데이터로더 단점은 로더 로직 처리시에 in-memory 혹은 레디스에 키를 들고있어야되서 메모리 사용이 파악할수없는 무한대로 오를것임

- 데이터로더는 또한 끝내는 그래프에 더 많은 요구사항 넣을때마다 개발에서 복잡함만 추가함


4. APQ (automatic persisted query)

- 그레프쿼리를 CDN 에서 케싱하려면 이방법이 주로 추천되는거로 검색나오는데 이건 결국 유저가 원하면 쓰지않고 우회해서 일반 쿼리로 서버 난사 가능함 결국엔 (그걸 경험도 해봤고)

- 그레프쿼리 CDN 케싱 은 APQ 로만 할수있는게 아님 ㅇㅇ


등등등...

 

이제 밥먹으러 가야지