GraphQL을 공부하면서 느낀점
SOAP, REST, GraphQL
지금까지 개발을 해오면서 3가지 API 아키텍쳐를 사용해왔다.
처음에 아무것도 모르는체 SOAP이라는 방식을 사용해서 개발을 했었는데
SOAP은 http를 사용하여 XML로 데이터를 주고 받았다. 여기서 메소드는 get과 post만 사용했음
SOAP은 대형 벤더(?) IBM, ORACLE 등 에서 SOA 사상을 구현 할 수있는 수단으로 밀면서 처리를 했다.
여기서 여러가지가 있는데 SOAP도 계약의 의한 설계가 가능하다 그것은 end point에서 wsdl을 노출하면서 해당 서비스의 input, output 타입을 노출하면서 가능했다.
SOAP에서 REST로 넘어간것이 SOAP은 어렵다는 이야기가 많았다. 그런 이유가 XML,XSD등을 공부해야 할것이 많아서 그랬던거 같다.
그러면서 REST로 넘어갔는데 지금 몇년전까지만 해도 그런것을 못느꼈는데 이젠 완전히 REST는 표준(?)같은 느낌이다.
REST의 단점(?)은 첫번째 계약에 의한 설계가 힘들다 요즘에는(오래전부터 나왔던거 같은데…) swagger, wadl 등을 활용하여 처리할려고 하는것 같다.
또 리소스 단위로 조회를 하다 보니 overfetching 과 underfetching 이 일어나고 있다.
overfetching은 클라이언트가 실제로 페치 할 때 필요하지 않은 데이터를 검색 중임을 의미
따라서 앱의 성능이 떨어지고 (더 많은 데이터를 다운로드하고 구문 분석하는 데 더 오래 필요) 사용자의 데이터도 많이 소진한다.
underfetching은 API 응답에 충분한 데이터가 포함되어 있지 않음을 의미 그래서 클라이언트가 현재 데이터 요구 사항을 충족시키기 위해 추가 API 요청을해야 함
이 문제를 해결하기 위해 페이로드를 수정하는 경우도 있지만 앱 과 백엔드가 업데이트를 위해 같이 움직여야 한다.
위 같은 문제가 생기면서 지금 GraphQL이 대안으로 떠오르고 있는것 같다.
GraphQL과 SOAP의 유사점은 두 프로토콜 모두 데이터 유형을 명시 적으로 선언하므로 응용 프로그램 간의 통신이 명확하다.
그리고 둘다 단일 end point url을 사용한다.
그리고 GraphQL이라는 단어에서 보듯이 쿼리를 지원한다. 그리고 데이터 변경을 위한 mutations 또 반응형 구독을 위해서 subscription을 지원한다.