가장 현대적인 웹을 만들자 3편 (GraphQL)
- 웹 개발에 대한 전반적인 배경 지식이 필요합니다.
- 가장 현대적인 웹 구조 중 하나인 Node.js, React, GraphQL, Apollo, Prisma, Next.js에 대해 소개합니다. 개발 강의는 아닙니다.
- 궁금한 것이 있다면 여기로 문의 주세요. https://open.kakao.com/o/gHobZuDb
GraphQL은 Facebook에서 REST API의 대안으로 개발을 진행 해 온 프로젝트다. 2015년에 처음으로 공개적으로 릴리즈 되었고 2016년 10월에 Stable 버전이 처음으로 공개된 후, 2년도 안되었으니 상당히 초기의 프로젝트다.
초기인데도 불구하고 Airbnb, Github, Atlassian, Coursera, Meteor, Twitter, Paypal, Yelp, Shopify 등 GrpahQL을 도입하고 있는 기업들이 상당히 많아지고 있다. (https://graphql.org/users/) 공개된지 얼마 안된 기술인데도 이정도로 도입할 정도면 기존의 Rest API에서 갖고 있던 Pain Point를 제대로 해결을 해 나가는 (혹은 그럴 것이라 기대되는) 기술로 볼 수 있을 것 같다.
Airbnb에서 GraphQL 도입에 관련된 글을 첨부 해 보았다.
https://medium.com/airbnb-engineering/reconciling-graphql-and-thrift-at-airbnb-a97e8d290712
우리는 GraphQL, Apollo (GraphQL 관련 라이브러리)에 관해 다시 한번 회의를 진행하기로 했다. 그것들이 주는 아래의 이점들이 너무나도 강력하기 때문이다.
1. 타입 기반 API 스키마 작성 가능
2. 데이터 요청의 유연함 (필요한 데이터만 요청 가능)
3. 크로스 플랫폼 개발의 용이성
4. Apollo가 주는 캐싱, 분석 도구, 상태 관리 등의 이점
GraphQL은 REST API와는 많은 부분이 다르다. 그럼 GraphQL은 무엇이고 현재 어느 수준까지 온 것일까?
REST API
REST API는 직관적이고 구현하기 단순하다. 브라우저단에서 캐싱이 되고 확장하기 용이하다. REST는 SOAP(REST 이전의 XML 기반 통신)에 비해 굉장히 가벼웠고 이는 REST가 널리 퍼지는 계기가 된다.
요청이 단순한만큼 데이터가 복잡해질수록 페이지 구성을 위해 네트워크 요청이 여러번 이뤄져야 하는 경우가 빈번했고 SOAP가 갖고 있던 타입 기반의 데이터 교환은 잃어버렸다. 이는 REST API를 잘 설계하기가 상당히 까다로운 일이 되었다는 것을 의미한다.
그렇다면,
- 데이터 수요자인 프론트앤드에서 필요한 데이터를 스스로 요청할 수 있으면 어떨까?
- 처음부터 필요한 데이터를 다 요청하면 어떨까?
- 백앤드와 프론트앤드에서 동일한 타입으로 데이터 요청/응답 관리를 할 수는 없을까?
이를 해결할 수 있는 것이 GraphQL이다.
GraphQL
위의 1, 2, 3번에서 SOAP가 연상이 될 수 있을 것이다. GraphQL은 완전히 새로운 개념이 아니라 기존의 개념이 REST API시대에서 다시 태어난 것에 가깝다.
GraphQL은 모든 것이 타입 기반으로 이뤄진다. 이 타입은 서버와 클라이언트 공통적으로 활용할 수 있기 때문에 엄격한 데이터 전송 관리가 가능하다.
아래는 Node.js 기반의 전체 예제 코드이다.
위에서 눈여겨 볼 부분은 2가지이다.
- 타입 구현 : GraphQL에서 사용될 모든 타입을 정의한 내용이며 별도의 파일로 분리하여 클라이언트단과 공유가 가능
- 함수 구현 : GraphQL 스키마 구현 뒷단에서 실제 실행되는 함수를 구현
그리고 4000포트의 localhost로 접속하면 테스트할 수 있는 화면이 뜬다.
왼편의 쿼리에서 id와 title만 요청했을 때 해당 데이터만 응답으로 온다.
위의 쿼리는 잠시 눈 여겨 볼 필요가 있는데 Writers에 posts를 포함해서 쿼리를 날리면 posts에 해당하는 내용을 포함해서 온다. 근데 기존의 구현된 함수를 보자.
기존의 구현된 함수는 하드코딩된 Writers만 리턴한다. 근데 하드코딩된 Writers는 posts에 id값만 들어있다. 그럼 어떻게 query에서posts를 찾아서 불러올 수 있었을까? 그 순서는 다음과 같다.
- Writers 하드코딩 된 배열을 리턴한다.
- Writers 하드코딩 된 배열
- 정의된 Writer Type과 배열의 Element가 같으므로 Element의 타입을 Writer로 인식한다.
- 배열의 Element마다 Writer Resolver를 실행, posts를 검색해서 최종적인 배열을 리턴한다. 최종 형태는 초기 query 형태에 따른다. 그렇게 아래와 같은 형태를 최종적으로 리턴한다.
위에서 보아왔듯이 GraphQL은
- 타입 기반
- 원하는 데이터를 그대로 받아올 수 있음
- Foreign Key 를 이용한 검색 시, 한번의 데이터 요청으로 검색 가능 (REST도 설계에 따라 가능하지만 설계가 유연하진 않다, 때때로 어떤 요청은 다른 요청의 응답이 온 후에 보내야 하기도 한다.)
기존의 REST에서는 프론트에서 Post의 Title만 받아오는 요청이 필요하면 백앤드 개발자와 설계 및 구현을 다시 거쳐야 했다. 근데 GraphQL에선 프론트앤드에서 바로 필요한 데이터만 요청을 날릴 수 있다.
또한 타입, 메서드 관리가 가능하고 클라이언트가 유연하게 데이터를 요청/전송할 수 있기 때문에 RPC(Remote Procedure Call)를 훌륭하게 활용할 수 있는 가능성도 보이고 있다. GraphQL이 DB에서 단순히 데이터 조회, 변경만 하는 것이 아니라 그 이상의 잠재성이 있다는 의견이 개발자들에게서 나오고 있다. (https://sites.google.com/a/athaydes.com/renato-athaydes/posts/thereturnofrpc-orhowrestisnolongertheonlyrespectablesolutionforapis)
GraphQL의 사용은 아직은 개발자들 사이에서 의견이 분분한 것 같다. 아래 링크에 상당히 많은 개발자들이 눈여겨 볼만한 의견들을 내놓고 있다. 그래도 전체적으로는 진보하는 흐름이란 것은 공감하는 것 같다. https://news.ycombinator.com/item?id=17565508
몇가지로 요약을 하자면
[단점]
- 캐싱, 예외 처리에서 불편
- Node.js 기반의 툴이 많아 Node.js를 안쓸 시, 서버단에서 구현이 번거로움
- 높은 러닝커브
- 프론트앤드에 비해 백앤드단 툴이 부족
[장점]
- 쉽고 유연한 구현
- 타입 기반
- 활발한 커뮤니티
- 프론트앤드 적용은 확실히 효과적
이렇게 정리할 수 있을 것 같다. 관련 생태계가 정말 빠른 속도로 발전하고 있고 GraphQL이 해결할 수 있는 포인트가 너무나도 확실하기 때문에 전망은 밝을 것이라고 생각한다.
현재 GraphQL 기반으로 가장 빠르게 같이 성장하고 있는 툴은 Apollo와 Prisma가 있다.
Apollo는 Meteor 를 만들었던 그룹에서 이끌고 있는 프로젝트이다. 얼마 안되었지만 이미 GraphQL 생태계 내에서 확고하게 자리 잡았다고 보아도 될 것 같다. Client, Server 단의 라이브러리, 캐싱 및 쿼리 분석도구를 제공한다. 특히나 React하고 결합 시 정말 Awosome 한 구현이 가능하다.
컴포넌트 자체에 Query를 녹여서 구현하기가 엄청나게 쉬워지는데 개인적으로 정말 이상적인 구현이 아닐까라고 생각하고 있다.
Prisma는 DB 프록시이다. GraphQL 개발자와 Heroku 창업자가 같이 진행 중인 프로젝트라고 한다. GraphQL 스키마를 기반으로 DB를 자동으로 생성해준다.
GraphQL 스키마 자체가 엄격한 타입기반으로 구성되어 있고 DB를 구현하기에 충분한 데이터가 있기 때문이다. MySql, Postgresql등의 스키마 및 쿼리를 자동으로 생성해준다. 사용자는 GraphQL 스키마만 설계하면 되고 DB를 설계할 필요가 없다.
상당히 급진적인 프로젝트이긴한데 많은 조명을 받고 있는 프로젝트이기도 하고 투자금도 꽤 받은 프로젝트이다.
GraphQL이 많이 성장하곤 있지만 REST API 를 온전히 대체할 정도까진 아닐 것이고, 외부에 제공하는 API는 REST로 관리되는 게 더 효과적일 것이라고 생각한다. 그러나 전반적으로 GraphQL이 갖고 있는 장점은 누구도 부인하지 않는 것 같다. 계속해서 한계를 깨려는 프로젝트들이 성장하고 있기 때문에 앞으로도 GraphQL 도입은 지속적으로 늘어날 것으로 보인다.
감사합니다.
- 궁금한 것이 있다면 여기로 문의 주세요. https://open.kakao.com/o/gHobZuDb
