tRPC v11은 오랫동안 @next 태그를 통해 프로덕션 준비 완료 상태였지만, 저희는 시맨틱 버저닝에 지나치게 얽매이지 않고 새로운 기능을 계속 추가해 왔습니다. 오늘, 마침내 tRPC v11의 공식 릴리즈를 발표하게 되어 매우 기쁩니다!

tRPC의 next 릴리스에서 이제 새로운 TanStack React Query 통합 기능을 사용할 수 있게 되어 기쁘게 생각합니다. 기존의 React Query 통합과 비교했을 때, 이번 통합은 더 간결하고 TanStack Query의 본질에 가까우며, 자체 클라이언트로 useQuery 및 useMutation을 래핑하는 대신 TanStack React Query의 기본 인터페이스인 QueryOptions와 MutationOptions를 직접 활용합니다.

tRPC v10에서 도입된 프로시저 생성용 빌더 패턴은 커뮤니티로부터 폭넓은 호응을 받았으며, 많은 라이브러리가 유사한 패턴을 채택했습니다. 이 패턴의 인기가 높아짐에 따라 tRPC like XYZ라는 용어까지 생겨났을 정도입니다. 실제로 최근 누군가가 tRPC와 유사한 API로 CLI 애플리케이션을 작성할 수 있는 방법이 있는지 궁금해하는 글을 보았습니다. 사족이지만, tRPC를 직접 사용하여 이 작업을 수행할 수도 있습니다. 하지만 오늘 주제는 이게 아닙니다. 오늘은 Next.js의 server actions와 함께 tRPC를 사용하는 방법에 대해 이야기해보겠습니다.

tRPC가 어떻게 동작하는지 궁금한 적 있으신가요? 프로젝트에 기여하고 싶지만 내부 구조가 두려우셨나요? 이 글은 tRPC의 핵심 작동 방식을 다루는 최소한의 클라이언트를 작성하며 내부 구조를 익히는 데 목적을 두고 있습니다.

TypeScript가 tRPC의 탁월한 DX를 가능하게 하는 핵심 동력이라는 것은 공공연한 비밀이 아닙니다. TypeScript 채택은 현대적인 JavaScript 기반 경험을 제공하는 표준이 되었지만, 이러한 타입 안정성 향상에는 일정한 트레이드오프가 존재합니다.

tRPC는 TypeScript의 강력한 기능을 통해 엄격한 풀스택 타입 바인딩을 강제함으로써 뛰어난 개발자 경험을 제공합니다. API 계약 이탈 없음, 코드 생성 없음.

tRPC는 타입을 선언하지 않고도 (Node) 서버부터 클라이언트까지 종단간 타입 안전성을 제공합니다. 백엔드에서는 단순히 함수에서 데이터를 반환하기만 하면, 프론트엔드에서는 엔드포인트 이름을 기반으로 해당 데이터를 사용할 수 있습니다.