회사 및 개인의 모든 최근 프로젝트 next.js퍼블리싱을 담당하는 부서는 주로 SEO 관련 문제를 해결하며 카테고리 상관없이 사용하고 있지만 한편으로는 React 진영의 라이브러리로 편하게 개발하고 싶은 분들도 계십니다. 하지만 Next.js를 가지고도 백엔드 컨트롤러 부분, 즉 클라이언트 요청을 직접 받는 부분을 개발할 때 답이 명확하지 않습니다. Axios를 사용한 계층화는 소규모 프로젝트에서 서버 간 통신을 구현할 때 충분합니다.그러나 API의 수와 크기가 증가함에 따라 Next.js는 다음을 지원합니다. API 하나의 폴더에 많은 코드를 집어넣는 것만으로는 충분하지 않습니다. 특히 API 엔드포인트 관리 및 유형 검사 자체는 상당한 피로를 유발할 수 있습니다.이 문제를 해결하는 것 중 하나는 tRPC모두. 혁신적 도서관이라고 소개하는 것만으로는 부족하지만, 지난 몇 달간 사용해본 결과 추천할만한 도서관이라 생각되어 소개해드리고자 합니다.
1. tRPC란?
프로젝트 이름 tRPC에서 추측할 수 있습니다. RPC(원격 프로시저 호출)유사한 이름으로 개발되었습니다(Google의 gRPC이름이 비슷한 것 같습니다.) 간단히 말해서 RPC는 다른 공간에서 ‘실행 파일’을 실행하는 것으로, 백그라운드에 있는 것이 포그라운드에서 실행되기 때문에 이름이 붙여질 수 있습니다. 기능별 해체에 순응하여 프로젝트 파생을 위한 네이밍 방식으로도 볼 수 있을 것 같습니다.
이 라이브러리를 설명하는 가장 빠른 방법은 ‘Typescript와 함께 GraphQL을 떠나는 성가심‘ 제 생각에는.
그래픽 QL반대로 GraphQL의 분노 중 하나인 스키마 생성을 Typescript 기반 인터페이스(또는 유형)로 대체하면서 추가 빌드 또는 코딩 프로세스가 필요하지 않습니다.요즘 자주 보는 조드요청 매개변수의 유형을 확인하는 데 사용됩니다. 특히 라이브러리 자체가 Typescript의 제네릭을 사용하여 생성되기 때문에 클라이언트와 백엔드에서 동일한 방식으로 응답을 요청하거나 받을 수 있습니다. 코드를 작성한 후 프론트엔드와 백엔드에서 자동으로 코드를 완성할 수 있는 객체를 사용하여 요청을 호출하거나 수신할 수 있어 전반적인 개발 효율성을 높이는 데 중요한 역할을 합니다.
2. TRPC란 무엇입니까?
최근의(구식이긴 하지만) FE 경향을 살펴보고 다시 설명하겠습니다.
디바이스 성능의 향상과 웹사이트의 복잡화로 인해 사용자에게 보여지는 페이지, 즉 프런트엔드에서 요구하는 사양이 점점 더 복잡해지고 있어 빠른 개발이 요구되고 있습니다. 그래서 FE 개발자들은 정말로 FE에 집중할 수 있기를 원하고 다양한 교육 기관에서 그것을 가르친다는 것을 알고 있습니다. 이러한 이상적인 환경은 아래 그림과 같습니다.
그런데 실제로 서비스를 실행해보니 예상대로 되지 않았다. 물론 기술적인 문제 외에도 크게 두 가지 문제가 있다. 첫 번째는 책임과 관리의 문제입니다.많은 서비스가 MSF 형식으로 이동함에 따라 운영 도메인(서버)의 수가 증가하고 필요에 따라 확장되지만 무거운 백엔드를 연결하지 않습니다. 두 번째는 개발주기입니다.FE의 빠른 주기는 상대적으로 느린 BE의 배포 주기와 일치하지 않습니다. 특히 유지보수 단계에 진입할 때 편차가 가장 크다. 성능이나 설계 변경 등 여러 가지 이유로 FE 분배가 잦은 경우 BE 관점에서는 의미 없는 분배만 수행할 수 있습니다. 마지막으로 FE의 서버를 분리하여 FE의 API 게이트웨이 서버 – Backend For Frontend, BFF 서버를 구성합니다. 문제는 여기서 시작됩니다. 비즈니스 로직을 BFF 서버로 분리하는 것은 좋지만, 서버에 대한 요청 및 사용자 인증 정보 처리와 같은 프런트 엔드에서 사용하는 로직은 어떻게 처리해야 할까요? 결국 FE 개발자가 관리하는 백엔드 서버에서 해야 합니다. 가볍지만 결국 풀스택 개발로 돌아갔습니다. 결과적으로 서비스는 결국 아래와 같은 구조가 됩니다.
좋은 친구(데이터 전송을 위한 API 게이트웨이) 서버는 핵심 데이터 처리를 위한 API를 제공하고, FE에서 관리하는 서버가 되어 사용자 요청을 직접 수신합니다. FE의 백엔드는 유지보수를 위해 통일된 언어가 필요하므로 SSR 또는 Node.js 생태계의 다른 기능(확장성 및 해당 성능 모두)을 지원하는 프레임워크를 선택해야 합니다. 이 경우에도 프런트엔드 프레임워크를 사용해야 하며 Next.js 또는 Nuxt.js 기반의 프로젝트만 선택할 수 있습니다. 어쨌든 FE가 관리할 서버는 준비되었습니다. 하지만 클라이언트가 직접 호출하는 API 엔드포인트 부분이 문제가 됩니다. FE 호출 요청 리버스 프록시 처리할 API 끝점을 관리하는 명확한 방법이 없습니다. 문서가 많고 빠르게 변경되며 문서가 없으면 관리가 전혀 불가능합니다.
이 경우 API를 호출할 수 있도록 객관화 라이브러리로 만드십시오. tRPC입니다.
물론 tRPC는 백엔드 컨트롤러에 해당하는 부분까지 지원하기 때문에 BFF로 구성되지 않은 일반 서비스에는 충분하다. 내 개인 프로젝트 중 하나에서 모든 응답은 tRPC에서 직접 처리됩니다. DB에 연결하여 데이터를 처리하는 방식은 일반적인 Node.js 백엔드와 동일하지만 컨트롤러 부분이 tRPC로 대체된다는 점만 다릅니다. 따라서 tRPC를 통해 백엔드 개발과 프론트엔드 개발이 밀접하게 연결됩니다. 이 접근 방식은 이전의 전체 스택 개발과 유사하지만 단순히 동일한 언어를 사용하고 동일한 코드로 동일한 프로젝트에서 개발하는 것 이상이므로 개발자는 여러 프로젝트에서 강력한 생산성 향상을 얻을 수 있습니다.
생각해보면 tRPC 사용의 장단점은 다음과 같습니다.
이점
- 강력한 생산성
- 성능 저하 없이 매우 빠르게 개발할 수 있습니다.
- Next.js / Express.js에 쉽게 적용할 수 있는 어댑터 제공
- 백엔드 프레임워크의 요청 및 응답 객체와 함께 세션 또는 쿠키를 사용할 수 있습니다.
- API 끝점을 클라이언트 호출 가능 개체로 제공
- 자동 완성 및 유형 유추 활성화
- 리팩토링 및 유지 보수 상황에서 큰 이점
- Zod 및 Typescript 유형(인터페이스) 정의는 GraphQL 스키마 선언보다 더 간단하고 능동적입니다.
- Typescript 유형 유틸리티 함수 또는 lodash 유틸리티 함수를 사용하여 유형을 쉽게 사용할 수 있습니다.
- 최신 유행의 쿼리 반응 캐시는 다음을 기반으로 합니다.캐시/부실 시간) 또는 페이지 매김 처리기 기능을 사용할 수 있습니다.
- 일반적으로 추가 작업이 필요하지 않습니다.
피해
- 프로젝트에서 사용하려면 추가 설정이 필요합니다.
- 여러 API 엔드포인트가 없다면 사용하지 않는 것이 가장 좋습니다.
- 클라이언트가 React-Query를 기반으로 하므로 학습 곡선이 있을 수 있습니다.
- 고객 내부 API 받기사용하기 때문에 시간 초과가 없습니다.
- 특별한 경우를 제외하고는 필요하지 않음
- 라우터-하위 라우터로 구분된 라우터 수준(컨트롤러) 관리 필요
- 백엔드에 대한 요청은 매우 간단하므로 추가 크롤링 및 제한이 필요합니다.
- @upstash/RateLimiter작동하지만 장치를 설정하거나 처리하는 데 어려움이 있을 수 있습니다.
- 전공이라고 보기도 어려워서 언제 잘못됐는지 정확히 지적하기가 어렵습니다.
- API doc, Rest Doc 등의 테스팅 도구 적용이 어려움
3. tRPC 구성 및 예시
Next.js + tRPC 샘플 코드: https://github.com/partnerjun/trpc-next-example
이러한 모든 기술과 마찬가지로 tRPC는 추가 장애물을 극복할 수 없습니다. 그러나 tRPC 구성은 매우 간단하며 Spring 구성만큼 복잡하지 않고 지속적으로 업데이트됩니다. Github에 올라온 이 프로젝트를 보면 별다른 설명 없이 바로 이해할 수 있을 것 같다. 다만, 직접 건너뛰기에는 아쉽기 때문에 아래에서 주요 코드를 설명하도록 하겠습니다.
tRPC 구성의 시작점은 server/context.ts 파일입니다. 이 컨텍스트 선언을 통해 다양한 기능이 개발됩니다.
tRPC 컨텍스트 선언(server/context.ts)
context.ts 파일은 tRPC 컨텍스트가 선언되는 위치입니다. createContext는 아래에 설명된 쿼리/변형에서 ctx 객체인 객체를 반환합니다. session, redis 또는 특정 헤더 값과 같이 요청에서 처리해야 하는 값을 등록하여 쉽게 개발할 수 있습니다. 이 값은 서버에서 호출한 요청에 채워지지 않습니다. 어떤 의미에서 이는 서버가 tRPC 클라이언트를 호출할 때 기본적으로 클라이언트의 요청 개체에 대한 액세스 권한이 없기 때문에(프레임워크마다 차이가 있음) 자연스러운 현상입니다.
tRPC 라우터 선언(서버/라우터)
tRPC의 라우터는 백엔드의 컨트롤러 부분으로 tRPC를 사용함에 있어 가장 중요한 부분입니다. tRPC 버전 10부터 가이드는 라우터와 하위 라우터로 구분되는 트리 구조를 개발합니다. 오른쪽 그림에서 publicProcedure로 시작하는 선언에 특히 주의하십시오. 우리가 알고 있는 프로세스 이름이 tRPC의 동작 방식과 관련이 있는지는 의문이지만, 이 객체를 이용하여 요청을 받는 컨트롤러 객체를 선언하고 선언된 객체를 메인 라우터에 연결하면 요청을 처리할 수 있습니다.
선언부는 크게 입력부와 조회/변경부로 나뉘며, 입력부에서는 요청 시 사용할 타입을 선언한다. 먼저 입력 함수에서 클라이언트 요청이 사용하는 값 유형을 zod로 선언합니다. 이 형식이 충족되지 않으면 오류 요청에 자동으로 응답합니다. 그런 다음 논리를 처리하기 위해 쿼리/변형이 선언됩니다. 이렇게 호출된 쿼리/변형은 http 요청의 GET/POST에 해당합니다. 이 함수에서 매개변수로 전달된 입력 객체는 위에서 선언한 타입에 해당하는 데이터를 받을 수 있고, ctx는 컨텍스트에서 선언한 데이터를 받을 수 있습니다. 이 부분은 위에서 설명한 컨트롤러와 매우 유사하므로 추가 설명이 필요하지 않습니다.
Next.js 페이지 파일(pages/index.ts)
다음은 라우터에 선언된 엔드포인트를 tRPC 클라이언트로 호출하는 코드입니다. 여기서 특별한 점은 브라우저에서 호출되는 클라이언트를 trpc라고 하고 백엔드(SSR)에서 호출하는 코드를 sTrpc라고 합니다. 서로 다른 환경이 서로 다른 클라이언트를 사용하기 때문입니다.
trpc 클라이언트는 위의 자동 완성을 지원합니다. testRouter는 라우터에서 ‘test’로 선언되고 testRouter에서 선언된 컨트롤러는 IDE에서 자동 완성을 위해 제안됩니다. 클레임뿐만 아니라 이 끝점을 호출할 때 필요한 값도 확인합니다.
4.결론적으로
이전에 쓴 것처럼 tRPC 자체가 혁신적인 기술이라고 생각하지 않습니다. 첫째, 인기 있는 GraphQL에서 tRPC를 사용하지 않는다고 해서 비슷한 것을 개발할 수 없다는 의미는 아닙니다. 특히 React-Query를 기반으로 하기 때문에 써보지 않았다면 막힐 때마다 짜증이 날 것입니다. 그러나 이 라이브러리가 제공하는 강력한 생산성은 무시할 수 없습니다. 앞서 언급한 바와 같이 BFF 기반 프로젝트의 특성상 역방향 프록시를 설정해야 하며, 이때 API 엔드포인트를 관리할 수 없는 경우 둘 다 사용할 수 있는 방법을 개발하는 데 주의가 필요합니다. 백엔드와 프론트엔드. 또한 Github Stars의 수가 빠르게 증가하고 있는 점을 감안할 때 프로젝트가 성공할 가능성이 높습니다.
물론 트렌드를 따라가는 것을 선택할 가치는 없지만 개인적으로 JPA-QueryDSL 트렌드보다 훨씬 가치가 있다고 생각합니다. 기존 기술을 쉽게 사용할 수 있게 해준다는 점에서 JPA와 비슷하지만 다른 프레임워크(또는 라이브러리)와 연동될 것이라는 가정하에 만들어졌고 더 큰 프로젝트의 경우 MSF에 적합합니다. 무시하십시오. 어쨌든 다음 프로젝트에서 tRPC를 사용할 계획이 있는지 묻는다면 그렇다고 대답할 것입니다.