graphql을 실무에서 써본지 4개월 됬다.
graphql 기본 문법이라던가, graphql에 edge(relationship) filter를 걸어보는 등 여러 가지 해본 것 같다.

그러면서 여러 가지 장단점을 느낀 거 같다.

장점

1. 잘 알려진 장점으로, graphql은 restapi와 달리 딱 필요한 데이터만 프론트에서 가져가 효율적이다.

2. sql 스키마에 edge만 잘 연결해놓으면, 프론트가 graphql을 통해 edge를 넘나들며 백엔드 api 구현을 기다릴 필요없이 데이터를 얻을 수 있다.

단점

1. graphql edge 깊이 문제가 있다. 아직 확실하게 조사하진 않았지만, 어떤 노드에서 edge를 5번 이상 타게 되면 깊이가 너무 깊어져서 쿼리 성능에 좋지 않다고 한다. 이에 관련된 최적화를 실무에서 연구할 필요가 있다. 사실 이건 단점이라기보단, 프론트 입장에선 주의할 점이라 볼 수 있고 백엔드 입장에선 최적화 지점이라고 볼 수 있긴 하겠다.

2. graphql의 edge는 장점이자 단점이라고 본다. edge를 통해서 프론트엔드는 백엔드 api 개발 일정에 대한 의존도를 많이 줄였다. 하지만 백엔드 입장에선 노드에 연결된 edge들에 대한 조건도 신경씀과 동시에 프론트가 쓰는 grapqhl 쿼리도 알아야 한다. 뭔가 프론트의 자유도를 위해 백엔드가 rest api보다 더 신경써주는 느낌이다. 흠... edge가 양날의 검이다...

백엔드로서 프론트엔드와 graphql 커뮤니케이션 유의점

백엔드에서 제일 먼저 graphql 스키마를 만들어줘야겠지만, graphql 스키마를 만들고 나서 프론트는 edge가 뭐가 필요하고 edge에 무엇을 연결해야하는지를 백엔드한테 다시 알려줘야 한다.

그렇지 않으면 백엔드에서 edge 관련 수정을 다시 해줘야 한다.