[GraphQL] GraphQL기술 회고 및 결론

728x90

출처 - https://codersociety.com/blog/articles/graphql-reasons

1. GraphQL 기술 회고

이전 포스팅에서 REST 기술로 만들어진 조회(GET), 생성(CREATE), 삭제(DELETE) API를 GraphQL로 만들어 보았다. GraphQL의 장점으로는 아래 장점이 가장 크다고 느꼈다.

- 하나의 EndPoint로 요청

- Overfetching문제 없이 데이터를 fit하게 요청

위 두 장점은 확실히 개발하면서 REST보다 좋다는 생각을 했다.

그럼 GraphQL이 REST를 대체할 수 있을까?라는 물음이 들 수 있다.

GraphQL이 REST를 완벽이 대체할 수 있는가?

- 공식문서
No, not necessarily. They both handle APIs and can serve similar purposes from a business perspective. GraphQL is often considered an alternative to REST, but it’s not a definitive replacement.

>>> GraphQL이 REST를 완벽히 대체불가(파일전송 이슈)

2. GraphQL 전환시 부작용

GraphQL이 가진 장점은 충분히 좋은 장점이지만 많은 여러기업이 아직 REST 기술을 고집하고 완벽히 REST를 대체하지 못하는 이유가 있다.

그 이유는 아래를 확인

▷ GraphQL로는 파일전송을 구현하기 까다로움

▷ 혼합(GraphQL, REST)해서 사용할 때 클라이언트의 불만(데이터 요청시 헷갈리고 GraphQL 쿼리문을 새로 익혀야 함)

▷ 기존 REST를 GraphQL로 변경할 떄 드는 비용 대비 효과가 낮음(검증된 효과가 없음)

▷ GraphQL은 기업에서 개발하는게 아닌 커뮤니티 드리븐 방식이기 때문에 확장성과 지속가능성이 불확실

3. 결론

위 부작용 중에 GraphQL로 전환시 클라이언트의 불만이 가장 큰 문제이다. 그렇기 때문에 GraphQL을 사용하는 대기업(Github, Netflix, Facebook 등)에서는 똑같은 기능을 하는 REST, GraphQL API 둘 다 만들고 클라이언트가 선택해서 사용할 수 있게 서비스 하고 있다.

그래서 내 의견으로는 아직 GraphQL로 API개발하는 것은 비효율적이며 시기상조라는 생각이다.

이상으로 GraphQL 기술 포스팅을 마친다.