REST API여 안녕

GraphQL + Apollo

기존 프로젝트에서는 당연히? REST API를 적용해서 server-client 작업을 해 왔다. 

나는 솔직히 REST API 말고 그 전 방식을 잘 몰라서 REST API 작업 말고는 잘 모른다. REST API는 server-client 간 약속만 잘 해 놓으면, 쓰는데 큰 문제는 없었다. 다만, 두 번의 프로젝트에서 프론트엔드, 백엔드 작업을 모두 해 보면서 REST API의 불편한 점은 아래와 같았다. 

- client에서 어떤 식으로의 data 가 필요한지 API 설계를 잘 해야 한다 (누구는 백엔드 쪽에서 만들어주는 대로 클라이언트에서 써야 하는 one-way 설계라고 했는데, 그건 공공 API일 때의 이야기인 것 같고, 우리 서비스 안에서의 client에서 쓰기에 최적화가 되려면 엄청난 천재 백엔드 개발자가 아닌 이상, 클라이언트랑 지속적으로 대화를 해야 한다고 생각한다)

- API 사용 매뉴얼 같은 문서를 잘 관리해야 한다 (업데이트가 있을 때마다 일일이 관리해줘야 하는데, 나는 이게 상당히 귀찮았다) 

- REST API는 상당히 정적이다. (static) 즉, client의 요구에 따라 동적으로(dynamic)하게 대응하기 쉽지 않다. 또, 필요에 따라 끊임없이 API를 만들어줘야 하는 경우가 생긴다. 또한 우리는 client에서 작업하기에 무리가 있는 부분들은 뭔가 상당히 비슷한 API인데도 불구하고, 여러 API variant 들을 가져가야 하는 경우도 있었다. 이 부분은 내가 잘 못해서 그런 것일 수도. 

출처: https://www.apollodata.com/

그런데!

facebook에서 GraphQL이라는 신 기술을 만들었다고 들었다. 

로고를 보면서 아 이제 js 로고 만드는데도 한계가 있구나 하는 생각

난 이걸 치맥 하면서 옆에서 말하는 것을 주워 들었을 뿐이다. '그게 뭐야?'라고 아무 관심 없이 넘어가 버렸는데, 집에 와서 심심해서 찾아보다가 '유레카!'와 같은 함성을 질렀다. 기존의 REST API에서 불편했던 위와 같은 부분들을 해결해 줄 수 있어 보였기 때문이다.

GraphQL이 무엇이냐. 공식 문서에 따르면 아래와 같다. 

GraphQL is a query language for your API, and a server-side runtime for executing queries by using a type system you define for your data. GraphQL isn't tied to any specific database or storage engine and is instead backed by your existing code and data.

정확히 해석은 아직 잘 안 되지만, 대충 보면 중요한 점이 우리가 원하는 방식대로 query를 날릴 수 있다는 말인 것 같다. 백엔드 쪽에서 만들어주는 대로 써야 하는 게 아니고, 프론트에서 원하는 데이터를 '이렇게 이렇게 찾아줘!' 하면 그냥 그대로 만들어준다는 것이다. 환상적이다. 심지어 JSON으로 query를 날리고, JSON으로 result값을 받게 된다. 자동으로. 

출처: http://graphql.org/learn/

DB Schema만 알면, 그게 바로 API 문서가 된다. 구조만 알면 query를 날릴 수 있다는 말이다. 즉, API문서 관리가 필요 없다. 왜냐하면 문서가 따로 없으니까. 이건 정말 굉장하다. 

GraphQL과 더불어 GraphQL-client가 몇 가지 있는데 내가 알게 된 client들은 facebook에서 만드는 Relay와 또 다른 client인 Apollo가 있었다. 며칠간의 research 끝에 Relay는 facebook에서 mobile 쪽 타겟으로 만들고 있고, 사용하기에 조금 복잡하다고 들었다. 그러나 Apollo는 모바일, 웹 등의 범용적인 목적으로 만들어지고 있는 오픈소스 커뮤니티라고 판단이 되어 Apollo GraphQL client를 적용하기로 했다. 또 리뷰 리퍼블릭 개발자님께서도 추천을 해 주시기도 했고. 아! 그리고 Apollo는 고맙게도 Redux-based 로 Redux에 친숙하다면 사용되는 방식이 Redux와 비슷해서 좋다. 

그렇다고 REST API를 버려야 하는가? 그건 아닌 것 같다. 왜냐하면 일단 외부 오픈 API를 쓸 때도 써야 하고, 내부적으로 API를 만들어 놓고 써야 할 경우가 있을 수도 있다. 굳이 매 번 query를 입맛에 맞게 보낼 필요가 없는 자주 쓰는 query들은 REST API로 만들어 놓고 써도 좋을 것 같다. GraphQL과 REST API는 공존이 가능하다. 

오늘은 우리 팀과 함께 Apollo가 적용되어있는 boilerplate branch를 받아서 우리 Github Repo에 pull request를 날리는 것까지 완료했다. 차주에는 백엔드 팀원 분과 함께 리뷰하면서 conflict가 나는 곳들을 살펴봐야겠다. 요즘 날씨가 끝내준다. 오늘은 토요일, 끝내주는 날씨 속에서 끝내주는 코딩을 해야지.