API 설계방식 (restful API / gRPC / graphQL) 비교

 

---

 

Restful API VS gRPC VS graphQL 차이점

API 설계(클라이언트 - 서버 통신)에 사용되는 메커니즘.

 

RestFul API 

클라이언트가 서버에 작업(POST, GET, PUT, DELETE)을 요청함. http(웹의 표준 통신 프로토콜)을 기반으로 함. 요청에 들어가는 endpoint에 추가 파라미터도 포함될 수 있음. 서버가 응답하면 전체 리소스를 클라이언트에 반환. 클라이언트는 서버에게 단일 REST API 요청을 전송하고, 서버도 단일 응답을 보냄. 클라이언트에서는 작업을 계속하기 전에 서버가 응답할 때까지 기다려야함. 데이터 교환 형식은 일반적으로 JSON임(XML, HTML도 가능함). JSON 단점 : 직렬화(serialize) 해야하고 프로그래밍 언어로 번역해야됨.

 

gRPC (Remote Procedure Calls)

RPC가 서로 다른 프로그램끼리 통신하도록 하는 프로토콜이고, Google에서 RPC 프레임워크를 개발한게 gRPC임. 클라이언트가 서버의 특정 함수를 직접 또는 간접적으로 호출함. 클라이언트가 여러 개의 API 요청을 서버에 보낼 수 있고 서버에서 여러 개의 응답이 발생할 수 있음(양방향 스트리밍). 1:1, 1:N, N:1, N:N 모두 가능함. 데이터 교환 형식은 기본적으로 Protobuf(Protocol Buffer)임. (JSON도 가능함) 데이터 구조를 바이너리 형식으로 serialize 하고 프로그래밍 언어로 deserialize함. 그래서 JSON보다 더 가볍고 빠름. Protobuf 형식은 사람이 읽을 수 없음. MSA에 가장 적합한 기술임. Protobuf의 IDL(Interface Definition Language)만 정의하면 클라이언트와 서버쪽 소스코드가 자동으로 생성됨. 우리 서비스에서는 백<->백 또는 백 <->AI 이런 식으로 통신할 일이 많음. 개중에는 PDF나 이미지 자료를 통신해야 할 때가 있는데 바이너리 데이터를 RestFul API에서 쓸 데이터인 JSON으로 바꾸는 과정에서 base64 인코딩을 할 때가 있는데 그러면 용량이 매우 커짐. 그래서 바이너리 데이터로 통신하는 gRPC를 도입할 필요가 있음.

 

GraphQL

클라이언트가 서버에 어떤어떤 데이터 달라고 쿼리 날리는 것. 프론트 쪽에서 API의 request/response 형식에 의존하지 않고 클라이언트에서 필요한대로 쿼리를 작성하므로 원하는 데이터만 가져올 수 있음. 원래는 백이 프론트에게 API 정의서 넘겨주면 프론트가 그거 보고 작업함. 그럼 프론트가 뭐 필요하면 백한테 이거이거 넘겨주는 API 넘겨달라고 하면 백은 바빠서 잘 안 해주거나 or 데이터 여러개 넘겨주는 API 써서 그중에 필요한 것만 뽑아쓰라고 함. 근데 그러면 불필요한 정보를 보내느라 통신이 느려질 수 있고, 개발도 느려짐(백이 뭔가를 해줘야 프론트가 시작할 수 있는 일도 생겨서) 그래서 나온 방법이 graphQL임. 이건 프론트가 필요한 데이터를 달라고 직접 쿼리를 줄 수 있음! 그래서 불필요한 정보 통신 안 하므로 통신이 빨라져서 사용자 화면이 빨라지고 개발도 빨라질 수 있음. 물론 사전에 약속을 잘 해야하고, 백에서 공통화를 많이 해놨어야 하고 프론트도 DB랑 리소스에 대해 알아야 쿼리를 잘 작성할 수 있을 것임. 그니깐 개발 시작 전에 약속할 것이 많음!! 그래서 프론트에는 Restful API와 graphQL을 필요한 곳에 적절히 넣어 사용할 예정임!!