Какие архитектурные решения tRPC навязывает вокруг rendering, state, routing, styling, data loading или deployment?

Что tRPC реально навязывает

tRPC позиционируется как «unopinionated», но ряд архитектурных решений вытекает из его природы:

1. Язык: только TypeScript

Весь смысл tRPC — в переносе типов AppRouter на клиент. Это возможно только если оба конца написаны на TypeScript. Клиент на JavaScript технически работает, но теряет все преимущества.

2. Сервер: Node.js-совместимая среда

tRPC-адаптеры существуют для Express, Fastify, Next.js (API Routes + App Router), Bun, Cloudflare Workers и Fetch API. Нет адаптеров для Go, Python, Java — сервер обязан быть JS/TS.

// Next.js App Router adapter
import { fetchRequestHandler } from '@trpc/server/adapters/fetch';
import { appRouter } from '@/server/router';

export const GET = (req: Request) =>
  fetchRequestHandler({
    endpoint: '/api/trpc',
    req,
    router: appRouter,
    createContext: () => ({}),
  });

export const POST = GET;

3. Deployment: клиент и сервер деплоятся вместе

В отличие от REST с версионированием, tRPC предполагает, что типы клиента всегда соответствуют типам сервера. Если деплоить их независимо, можно получить runtime-ошибки при несовпадении схем. На практике это означает монорепо с совместным CI/CD.

4. Data loading: де-факто React Query

@trpc/react-query — официальная интеграция. Можно использовать tRPC без React Query (vanilla client), но тогда теряются кэш, дедупликация, optimistic updates. Большинство проектов строят data-слой вокруг React Query.

5. Rendering: нейтрален, но есть нюансы с RSC

tRPC работает с CSR, SSR (через getServerSideProps или createCaller), SSG. В Next.js App Router серверные компоненты используют createCaller, а клиентские — хуки. Это создаёт два паттерна в одном проекте.

// RSC: прямой вызов без HTTP
import { createCaller } from '@/server/router';
import { createContext } from '@/server/context';

export default async function Page() {
  const caller = createCaller(await createContext());
  const posts = await caller.post.list();
  return <ul>{posts.map(p => <li key={p.id}>{p.title}</li>)}</ul>;
}

6. Routing и styling: полностью нейтрален

tRPC не касается router (Next.js, React Router, TanStack Router — любой), CSS (Tailwind, CSS Modules, styled-components — любой). Это чисто API-слой.

Подводные камни

• Два паттерна доступа к данным в RSC-проектах (createCaller в серверных компонентах и хуки в клиентских) усложняют onboarding новых разработчиков.
• Edge runtime ограничен. Некоторые адаптеры не поддерживают Node.js API; Cloudflare Workers требует fetch-адаптера и ограничивает использование нативных модулей.
• Нет встроенного кэширования на уровне CDN. GET-запросы через httpLink кэшируются браузером, но batch-запросы (POST) — нет. Нужен явный httpLink для query-процедур.
• Монорепо не обязателен, но без него больно. Без shared-пакета с AppRouter нужно вручную синхронизировать типы между репозиториями.
• Versioning отсутствует из коробки. Нет встроенной поддержки /v1/, /v2/; приходится решать через отдельные роутеры или namespace-конвенции.

• Знать термины tRPC, но не понимать связи между абстракциями
• Объяснять поведение через отдельные примеры вместо причинной модели
• Не связывать mental model с диагностикой ошибок

• Понимает ключевые абстракции tRPC
• Может предсказывать поведение системы через mental model
• Связывает модель с debugging и production decisions