너와 나의 프로그래밍
Development Etc. - GraphQL 본문
요즘 프론트엔드 개발을 하면서 GraphQL을 많이 쓰는 추세다. 새로운 기술을 도입하는 스타트업 같은 경우에 유독 많이 사용하는 듯 하다. 여러 채용공고를 보면서 Recoil이라든지 React-Query라든지 여러가지 많은 라이브러리들을 사용하는 것 같다.
도대체 GraphQL이 뭐길래 이렇게 도입을 하는 것일까...?
🤔 What Is "GraphQL"
GraphQL은 Facebook이 2012년에 개발하여 2015년에 공식적으로 배포한 "데이터 질의어"다.
"질의어"란 Query Language를 말하는데 말 그대로 Query Language를 사용해서 API 통신을 할 수 있게 만들어준다.
간단하게 기존의 RESTful API를 불러오는 방식(예: Promise, fetch, Axios, ajax 등등...)을 Query문을 사용해서 불러올 수 있다.
🤔What is the difference between GraphQL and RESTful API?
RESTful API의 대체로 나온 GraphQL과 어떤 차이가 있을까?
1. 호출 방식 : GraphQL과 RESTful API의 가장 큰 차이점은 "엔드포인트(EndPoint)"의 관리다.
GraphQL(GET) : "https://aaa.com"
RESTful API(GET) : "https://aaa.com/bbb?=..."
GraphQL은 엔드포인트를 하나의 도메인만 입력하면 되지만 기본 RESTful API의 같은 경우에는 수많은 엔드포인트를 갖게 된다. 엔드포인트가 너무 많으면 관리하기도 힘들고 같은 도메인 주소에 무수히 많은 Query String도 붙기 때문에 코드가 더욱 복잡해진다고 생각한다.
엔드포인트를 하나로 관리해서 API의 접근하는 점은 정말 획기적인 방법이라고 생각한다. 앞단에서 RESTful API를 호출할 때 항상 API를 사용하기 위해 URL Path를 계속 입력해줘야되는 점과 Query String을 계속 관리해줘야되는 점은 조금(?) 번거롭고 불편하긴 했다. 하지만 GraphQL은 이러한 단점을 확실하게 보완한 듯 하다.
물론 개인적인 차는 있지만 확실하고 명확하게 API를 호출하고 관리하고 싶다! 라고 생각된다면 URL 작성이 맞지 않을까 싶기도 한다.
2. 모든 데이터를 가져오지 않고 내가 필요한 데이터만 쏙쏙!
기존 RESTful API의 GET 방식은 서버에서 만들어진 API를 URL 주소를 통해 한꺼번에 불러오는 방식이였다면 GraphQL은 "Query"를 작성해서 마치 데이터베이스 언어의 Select를 사용하는 거와 같이 내가 원하는 값만 쏙쏙 불러올 수 있다.
확실히 한꺼번에 많은 양의 데이터를 불러오는 방식 보다는 내가 필요한 데이터만 골라서 받아오는 방식이 API를 호출하는 시간도 절약되고 불필요한 데이터까지 한꺼번에 받아와서(Over-Fetching) 내가 원하는 데이터를 찾아 사용하기도 쉽지도 않은 점이 있다.
사실 협업을 하면서 Backend 개발자들에게 따로 값만 받아올 수 있도록 API를 요청해도 좋겠지만 그러면 Backend 개발자들은 비슷한 API를 계속 만들어야되고(Under-Fetching) 협업을 하는 과정에서 원치 않은 트러블(?)이 발생할 수도 있을 수 있어 이 점은 GraphQL의 아주 큰 강점이 아닐까 생각든다.😂
3. Typescript의 Type Alias처럼 사용할 수 있다.
문법 자체가 Typescript의 Type Alias를 선언하는 방식과 아주 유사하다.
자바스크립트의 기본적인 타입의 대한 불분명한 방식 때문에 협업에 어려움을 겪었던 점을 보완해서 나온 타입 시스템은 정말 큰 장점이라고 생각된다.
(요즘 Typescript를 많이 사용하는 추세인데 너무 다행인듯...😂)
4. File Upload처리는 복잡하다.
기본적으로 Client에서 API로 파일을 업로드 할 때는 ContentType을 "multipart/form-data"로 설정을 한다. 하지만 GraphQL은 기본적으로 JSON형식의 쿼리를 사용하므로 ContentType이 "application/json" 요청을 해야한다. 이러한 이유로 ContentType의 형식을 application/json으로 변경해 줄 수 있는 미들웨어도 있지만 개인적인 입장으로는 무조건 File 처리 같은 경우에는 그냥 RESTful API를 사용하는 점이 생산성도 좋고 관리하기도 편할 것 같다.
무조건 GraphQL이 좋은것!이라고 볼 수는 없으니...😁
👍마무리
GraphQL은 완벽하게 RESTful API를 대체하기에는 조금 무리가 있지 않을까 싶다. 지금 현업에서도 일반적인 RESTful API를 사용하는 곳도 많고 단순 호출을 하는 경우에도 굳이 GraphQL을 사용하지 않는것이 더 생산성이 좋을 수도 있을 것 같다.
뭐든 장점과 단점이 공존하는 양날의 검이라고 생각이 든 만큼 필요에 따라 적절하게 사용하는 방법이 제일 베스트가 아닌가 싶다.
물론 RESTful API와 GraphQL을 동시에 사용한다면 정말 마구잡이로 관리도 안되는 코드가 될 수도 있으니 적절한 비율을 두고 사용하거나 기획을 명확하게 사용하는 것이 좋을 것 같다.
'Etc. > Development Etc.' 카테고리의 다른 글
Development Etc. - MSW(Mock Service Worker) (0) | 2023.01.15 |
---|---|
Development Etc. - Recoil (0) | 2022.12.11 |
Development Etc. - Android/iOS Kakao PostCode Progressive (0) | 2022.05.09 |
Development Etc. - AWS Amplify '[ERROR]: !!! Build failed, !!! Non-Zero Exit Code detected' for Next.js or React.js (0) | 2021.10.28 |
Development Etc. - Styled Component(스타일드 컴포넌트) (0) | 2021.04.30 |