TRPC, GraphQL, Restful API

최근 사이드프로젝트를 만들 때, openapi-generator로 클라이언트, 서버, documentation을 생성해주는걸 사용해봤다. graphQL과 grpc+protobuf를 사용해봐서 어떤 느낌일까 사용해봤는데, yaml 파일에 ref를 통해 확장해나가는 방식이 꽤나 불편했다. typescript-fetch, typescript-node, typescript 뿐만 아니라 다양하게 client용 generator도 제공했지만 개발과정에 만족도는 높지 않았다.

요즘엔 FullStack Javascript 데이터 인터페이스로 TRPC가 많은 주목을 받고 있는듯 하다.

 

주요 특징은 다음과 같다.

• GraphQL이 API용 쿼리 언어인 반면 tRPC는 완전한 형식 안전(t는 TypeScript를 나타냄) RPC(원격 프로시저 호출) 프레임워크라는 것
• GraphQL을 사용하면 클라이언트가 API에서 필요한 데이터를 정확하게 지정할 수 있고 서버는 해당 데이터만 반환하는 반면, tRPC를 사용하면 서버는 클라이언트가 특정 작업을 수행하기 위해 호출할 수 있는 미리 정의된 절차 집합을 제공한다.
• GraphQL은 스키마를 사용해 프런트엔드와 백엔드 사이에 엄격한 경계를 그립니다, 반면 tRPC를 사용하면 백엔드에 이미 정의된 함수를 프런트엔드에 노출하거나 그 반대로 노출한다.
• tRPC는 클라이언트와 서버 모두에서 HTTP/2 지원이 필요하지만 GraphQL은 모든 HTTP 클라이언트와 함께 사용할 수 있습니다.
• GraphQL API는 일반적으로 HTTP를 전송 계층으로 사용하고 GraphQL 쿼리는 API에 대한 POST 요청으로 전송되는 반면 tRPC는 TypeScript를 사용하여 전체 애플리케이션에서 유형 안전성을 보장하는 라이브러리이다.
• GraphQL은 여러 데이터 소스를 처리하는데 더 적합하지만 스키마를 업데이트 할 때마다 타입들을 재생성해야 하는 반면 tRPC는 단순 컴파일 없이 라이브러리 처럼 import 할 수 있기에 사용하기에 쉬워 단일 코드베이스라면 더 적합하다.
• GraphQL은 자체 문서화 API를 제공하지만 tRPC는 공개 API를 만들기에 적합하진 않다.
• tRPC는 Next의 백엔드와 프론트엔드를 연결하는 데 도움이 됩니다. 많은 사람들이 Next.js가 서버에서 실행되기 때문에 실제로 백엔드 프레임워크의 정의에 적합하다는 사실을 잊고 있습니다. Next.js 스택에 tRPC를 추가하는 것은 전체 스택 애플리케이션에 대한 기술 선택을 단순화하는 좋은 방법입니다.

 

번들 사이즈

 

https://trpc.io/

tRPC - Move Fast and Break Nothing. End-to-end typesafe APIs made easy. | tRPC

https://cleancommit.io/blog/trpc-vs-graphql-how-to-choose-the-best-option-for-your-next-project/

tRPC vs GraphQL: How to choose the best option for your next project | Clean Commit

https://echobind.com/post/why-we-ditched-graphql-for-trpc

Why we ditched GraphQL for tRPC