글을 쓴 이유
GraphQL은 2019년쯤 개발을 하면서 제가 만든 서비스에 접목 시켜봤습니다. 그때는 새로운 패러다임이며 나도 맛좀 보고싶다라는 생각에 꾸역꾸역 접목 시켰던 기억이 있습니다. 그 후로는 접목시켜 사용하지는 못했습니다.
이유는 그 당시에는 REST API가 생산성이 훨씬 높다고 판단했기 때문입니다. 그래서 잊고 살다가 특정요청에 대한 API를 계속 만드는 작업과 유지보수의 문제로 골골대다 GraphQL이 생각나서 다시 공부해서 잘 써보자!! 라는 다짐하에 글을 쓰게 되었습니다.
GraphQL?
특징
첫 번째, Endpoint는 하나!
우리가 흔히 알고 있는 REST API에서는 다양한 Endpoint를 호출했습니다. 근데 GraphQL은 하나의 Endpoint를 제공하며, 단 한 번의 요청으로 모든 정보를 가져오게 됩니다.
두 번째, Over,Under Fetch의 해결방안!
클라이언트에서 Query로 서버에 데이터를 요청할 수 있다는 것에 출발하여 Restful API의 불편함을 만드는 Overfetch, Underfetch를 해결 할 수 있습니다.
먼저, Overfetch는 쉽게 사용하지 않는 데이터까지 가져오는 것입니다. 프론트단에서 변경이 이뤄진다면 불필요한 데이터가 넘어 올 수 밖에 없습니다. 그 외 여러가지 이유로 불필요한 데이터를 가져오게 되는 문제입니다.
Underfetch는 원하는 데이터가 한 번에 넘어오지는 것입니다. REST API에서는 각각의 원하는 데이터에 대한 GET API를 호출해야합니다.
이런 두 가지의 불편함을 GraphQL은 해결가능합니다. 위에서 언급했던 것처럼 Query로 서버에 데이터를 요청하기 때문에 이 두 가지에 대한 문제를 해결 가능한 것입니다.
제 생각에 REST API와 GraphQL와 비교하자면
REST API는 호출은 간단하지만 받아오는 데이터는 복잡
GraphQL은 호출은 복잡 받아오는 데이터는 명료
이렇게 비교 가능할 것 같습니다.
이번 프로젝트에서 GraphQL를 사용하는 이유?
1. 생산성 향상 , API 유지보수 최소화
2. GraphQL Playground(apollo)
3. 하나의 Endpoint
이렇게만 봐도 충분히 사용할 가치가 있다고 생각합니다.
물론 단점도 있습니다.
1. 복잡한 Query로 성능 저하
2. 캐싱이 어렵다
3. 파일 업로드의 문제
단점의 경우는 충분히 해결할 수 있는 수단이 있으며, 복잡한 Query를 지양하며 만든다면 이런 단점은 충분히 커버할 수 있다고 생각하며GraphQL의 매력을 더욱 느낄 것이라고 생각합니다.
이번 프로젝트는 무엇?
저는 이번에는 TodoList Project를 만들어보려고 합니다.
공부를 하기 위해 TodoList Project는 참으로 적합하다고 생각이 드네요 ㅎㅎ
그래서 먼저 Nestjs와 GraphQL로 백앤드를 구성해보고자 합니다.
후에는 프론트영역도 작업할 생각입니다. 프론트앤드는 뭘로 만들까는 좀 더 고민해보겠습니다.
마무리
이 글을 읽게 되시는 분들이 만약 GraphQL에 대해서 더 자세히 알고 싶으시다면 능력자분들께서 잘 정리해 놓은 특징, 장점 등 다양한 내용의 글들이 있으니 꼭 참고해주시면 좋겠습니다.
생각보다 시간을 많이 투자한 것 같지만 너무 허접한 많은 첫 글입니다.( 글쓰기도 성장하는 0seo가 되어 보겠습니다.)
다음글에서는 본격적으로 Nest.js와 GraphQL을 이용할 수 있도록 프로젝트 초기 구성해보겠습니다.
감사합니다.
'Backend > Nestjs' 카테고리의 다른 글
[Nestjs] Nestjs + GraphQL 적용한 TodoList 만들기 (4) (0) | 2022.02.14 |
---|---|
[Nestjs] Nestjs + GraphQL 적용한 TodoList 만들기 (3) (0) | 2022.02.07 |
[Nestjs] Nestjs + GraphQL 적용한 TodoList 만들기 (2) (0) | 2022.01.25 |