English Title: When REST is unrest, how about GraphQL or gRPC? 본 자료는 GDG DevFest 2020 모각코라네 라이트닝 토크 BE세션 발표자료입니다. 해당 발표는 유튜브에서 시청하실 수 있습니다. https://www.youtube.com/watch?v=cNffW-YVvVk

1. REST가 unrest할 때
GraphQL, gRPC는
어때요?
이형남, leohnlee@gmail.com
BE/Data Engineer, (주)두들린

2. 1. 도입 동기 및 기존 시스템
2. RESTful API
3. GraphQL의 도입
4. gRPC의 도입
목차

3. 도입 동기

4. 코딩에는 정답이 없다.
하지만 오답은 있다.

5. 동..동기화가 필요해..
FE BE AI

6. 리팩하기 귀찮지만 유연함은 갖고 싶어
FE BE AI
Graph
QL
gRPC

7. RESTful API

8. RESTful API는 쉽게 말해서...
HTTP 프로토콜을 사용하는 아키텍처로써
Resource(URI, data)를 정의된
Method(get, post ...)로 처리하는 것.
CRUD

9. 1. 표준의 부재
2. 데이터 사용자가 아닌 관리자의 입장에서 설계
3. Overfetching Vs. 사용자 종속적인 설계
4. JSON 기반의 느린 통신
5. 구현할 게 많다보니, Human Fault도 많다.
(문서 누락, 많은 구현량에 따른 많은 테스트)
RESTful API의 단점

10. GraphQL

11. 1. 페이스북에서 만든 쿼리언어
2. 일반적으로 HTTP 프로토콜 사용
3. 언어/플랫폼/네트워크 등에 종속적이지 않다
4. 단 하나의 Endpoint
5. 정의된 Schema를 기준으로
서버사이드에서는 Resolver를,
클라이언트에서는 Query를 구현
GraphQL로 말할 것 같으면

12. 단 하나의 Endpoint
https://www.apollographql.com/blog/graphql-vs-rest-5d425123e34b/

13. 단 하나의 Endpoint
https://worth.systems/insight-graphql-what-why-and-how

14. GraphQL은 쉽게 말해서...
정의된 스키마를 기반으로 통신.
Server는 관리에 최적화된 형태로 Resolver 구현
Client는 사용에 최적화된 형태로 Query 구현
Schema

15. 1. Resolver는 BE가, Query는 FE가 구현
2. 네트워크 비용 감소
3. API의 클라이언트 종속성 해소
4. 기능 확장에 유리
5. 모바일 등 클라이언트 확장에 유리
GraphQL을 적용하고 나서...

16. gRPC

17. 1. 구글에서 만든 RPC프레임워크
2. HTTP/2 프로토콜을 사용
3. 플랫폼/언어 등에 종속적이지 않다
4. 바이너리로 전송해서 JSON보다 빠르다
5. 양방향 스트리밍이 가능하다
6. Protocol Buffers 구현체를 기반으로 한다
gRPC로 말할 것 같으면

18. RPC(Remote Procedure Call)
https://grpc.io/docs/what-is-grpc/introduction/

19. 1. Unary:요청 1회-응답 1회
2. 클라이언트 스트리밍:연속 요청-응답 1회
3. 서버 스트리밍:요청 1회-연속 응답
4. 양방향 스트리밍:연속 요청-연속 응답
gRPC의 요청/응답 종류

20. gRPC와 Protocol Buffers
https://www.xenonstack.com/insights/google-protocol-buffer/

21. gRPC는 쉽게 말해서...
Protocol Buffers를 통해서 통신.
원격 머신을 로컬 함수를 호출하듯이.
네트워크 비용이 감소한다.
Function

22. 감사합니다