tRPC?

https://www.youtube.com/watch?v=abcnU7O5TVY
노마드 코더의 tRPC 영상을 보고 나서 자주 바뀌는 응답과 요청 때문에 답답해하고 있었는데, tRPC가 그런 문제를 해결해줄 것 같아 찾아봤다.

장점으로는

• 타입 안전성: 클라이언트와 서버 간에 타입을 공유하여 타입 안전한 API 통신을 보장합니다. 이는 개발 중 발생할 수 있는 타입 오류를 줄여주고, 코드의 안정성을 높여줍니다.
• 자동 완성 지원: TypeScript의 장점을 활용하여 IDE에서 자동 완성 기능을 사용할 수 있습니다. 이는 개발 속도를 높이고, 실수를 줄여줍니다.
• 간편한 설정: REST API나 GraphQL 설정보다 간단하고 직관적입니다.
• 성능 최적화: 필요한 데이터만 요청하고 응답할 수 있어 성능 최적화에 유리합니다.

장점에대한 단점이 있는데
지금 부터 설명할 단점으로인해 사실상 조금 큰 상용에서는 적용이 불가했다.

• TypeScript 의존성:tRPC는 TypeScript에 크게 의존합니다. TypeScript를 사용하지 않는 프로젝트에서는 사용하기 어렵거나 불편할 수 있습니다.
  TypeScript를 처음 접하는 개발자에게는 학습 곡선이 있을 수 있습니다.

• 생태계 제한:
  tRPC는 상대적으로 새로운 라이브러리로, 커뮤니티와 생태계가 REST API나 GraphQL처럼 크지 않습니다.
  이에 따라 예제, 문서, 서드파티 라이브러리 등이 부족할 수 있습니다.

• 서버-클라이언트 결합:
  tRPC는 서버와 클라이언트가 같은 타입 정의를 공유하는 구조이므로, 둘 사이의 결합도가 높아질 수 있습니다.

간단하게말해서, 요즘 많이 사용되는 Flutter(Dart) 등 여러 언어를 지원하지 않으며, 클라이언트에서도 서버 코드를 들고 있어야 해서 무거워집니다. 또한, 내가 주로 사용하는 NestJS 같은 프레임워크에서 API가 많아지면 실행 시 문제가 발생할 수 있어, 간단한 프로젝트에서나 사용할 수 있다.