trpc / next-13

experimental playground for tRPC + next.js 13

tRPC

Move fast and break nothing.
End-to-end typesafe APIs made easy.

The client above is not importing any code from the server, only its type declarations.

Note

You are looking at the next-branch of tRPC which is the current work in progress representing version 11.

• The functionality is stable and can be used in production, but we may do small breaking API-changes between patches until we reach 11.0.0
• The packages are published with the next-tag on npm
• For the list of changes made, see https://trpc.io/docs/v11/migrate-from-v10-to-v11

Intro

tRPC allows you to easily build & consume fully typesafe APIs without schemas or code generation.

Features

• ✅  Well-tested and production ready.
• 🧙‍♂️  Full static typesafety & autocompletion on the client, for inputs, outputs, and errors.
• 🐎  Snappy DX - No code generation, run-time bloat, or build pipeline.
• 🍃  Light - tRPC has zero deps and a tiny client-side footprint.
• 🐻  Easy to add to your existing brownfield project.
• 🔋  Batteries included - React.js/Next.js/Express.js/Fastify adapters. (But tRPC is not tied to React, and there are many community adapters for other libraries)
• 🥃  Subscriptions support.
• ⚡️  Request batching - requests made at the same time can be automatically combined into one
• 👀  Quite a few examples in the ./examples-folder

Quickstart

There are a few examples that you can use for playing out with tRPC or bootstrapping your new project. For example, if you want a Next.js app, you can use the full-stack Next.js example:

Quick start with a full-stack Next.js example:

# yarn
yarn create next-app --example https://github.com/trpc/trpc --example-path examples/next-prisma-starter trpc-prisma-starter

# npm
npx create-next-app --example https://github.com/trpc/trpc --example-path examples/next-prisma-starter trpc-prisma-starter

# pnpm
pnpm create next-app --example https://github.com/trpc/trpc --example-path examples/next-prisma-starter trpc-prisma-starter

# bun
bunx create-next-app --example https://github.com/trpc/trpc --example-path examples/next-prisma-starter trpc-prisma-starter

👉 See full documentation on tRPC.io. 👈

Star History

Core Team

Do you want to contribute? First, read the Contributing Guidelines before opening an issue or PR so you understand the branching strategy and local development environment. If you need any more guidance or want to ask more questions, feel free to write to us on Discord!

Alex / KATT

👋 Hi, I'm Alex and I am the creator of tRPC, don't hesitate to contact me on Twitter or email if you are curious about tRPC in any way.

Project leads

The people who lead the API-design decisions and have the most active role in the development

Julius Marminge

Alex / KATT

Active contributors

People who actively help out improving the codebase by making PRs and reviewing code

Nick Lucas

Flo

Sachin Raja

Special shout-outs

Chris Bautista

Theo Browne

Ahmed Elsakaan

James Berry

Kamil Ogórek

Sponsors

If you enjoy working with tRPC and want to support us, consider giving a token appreciation by GitHub Sponsors!

🥇 Gold Sponsors

Tola

🥈 Silver Sponsors

Cal.com, Inc.

🥉 Bronze Sponsors

Echobind

Dr. B

Flylance

😻 Smaller Backers

Ahoy Labs	Dyaa	Brooke	Max Greenwald	Tom Ballinger	Faraz Patankar
Adam Slaker	Dmitry Maykov	Chris Bradley	Ahmed Elsakaan	Hampus Kraft	Illarion Koperski
SchlagerKhan	Jared Wyce	fanvue	Andrew Brown	Ascent Factory	Unkey
Jonas Strassel	Jordy	Daniel Burger	Scale Leap	Drew Powers	Drizzle Team
Liran Goldman	Spencer McKenney	Proxidize	Oskar Hertzman	Imamuzzaki Abu Salam

All contributors ✨

---

next-13's Issues

Add prisma according to `next-prisma-starter`

Blocker for #9

Add prisma similar to https://github.com/trpc/examples-next-prisma-starter

I broke something

In #23 I tried to be smart. That seem to have been a mistake.

Use `post.create`

• Gotta be a client-side component
• Unsure if we should use react-query for mutation, we could or use @trpc/client directly

How to align the client/server DX?

Currently, we use rsc.* to fetch data on the server and trpc.* on the client.

I wish this was the same object used so you didn't have to care if you're on the server or the client.

tRPC 10 with Next 13 App dir

Thank you to anyone who takes the time to respond or share their thoughts on this matter.
With the condition that the app folder was used exsclusevly with client components (to gain access to the nested layouts feature),
is there a way to setup tRPC 10 to work in the app dir?

Thanks again

// FIXME is there typing for this?

next-13/app/layout.tsx

Lines 6 to 9 in 4acea77

	interface Props {
	// FIXME is there typing for this?
	children: ReactNode;
	}

Yup: import { PropsWithChildren } from "react";

npm install issue

npm install throws below error messages to console log

npm ERR! code ERESOLVE
npm ERR! ERESOLVE unable to resolve dependency tree
npm ERR! 
npm ERR! While resolving: [email protected]
npm ERR! Found: [email protected]
npm ERR! node_modules/next
npm ERR!   next@"^13.0.1-canary.3" from the root project
npm ERR! 
npm ERR! Could not resolve dependency:
npm ERR! peer next@"^12.2.5" from [email protected]
npm ERR! node_modules/next-auth
npm ERR!   next-auth@"4.14.0" from the root project
npm ERR!
npm ERR! Fix the upstream dependency conflict, or retry
npm ERR! this command with --force, or --legacy-peer-deps
npm ERR! to accept an incorrect (and potentially broken) dependency resolution.

probably, change version to next@"^13.0.3" from next@"^13.0.1-canary.3" and "next-auth": to "4.16.4", will work.

Add next-auth and use a `privateProcedure`

• I want to test protected pages
• I want to test non-public procedures how they feel

Open questions

Just dumping some thoughts / half-baked ideas here

• With RSC - is there a point of tRPC? Is there a "lighter" approach that might be nice(r)? Maybe, but not for all
• With RSC - is there a point of react-query? yes, there's still client components
• Will there be a way to sync state and make sync the underlying state of the queries from RSC -> client & make isomorphic components?
  • Biggest question - unsure how state sync can work from a root "use client" Provider that renders on the server to the client that uses it.
• Will importing the full router on every RSC-request add any significant overhead?
• Will React Context providers be available on the server? If so, it be possible to do any "isomorphic" context providers? Will components be able to be isomorphic? This was a misconception. We'll do a root "use client" component & likely not sync state from actual RSC-components to client
  • If query state could be synced from server to client and context providers + components could be isomorphic, we could do stuff like using optimistic updates of a component that was initially rendered on the server.
• How to deal with caching?
• [..]

Idea: hydrate `react-query` cache more automagically

The way we hydrate the react-query cache on the client is a bit convoluted and unnecessarily complex DX.

I think I could make mine a bit easier to deal with so it's more generic instead:

• In RSC, create a real queryClient from react-query & populate it's cache when calling stuff
• Pass queryClientData={hydrate(queryClient}} to the Client component
• Have a generic HOC on client components that expects a queryClientData & uses setQueryData

API on the server (here) could look something like:

Not that nice with HOC

// page.tsx
function PostListRSC() {
  const postList = rscClient.post.list.fetch({});

  return (
    <PostList
      queryClientData={rscClient.hydrate()}
    />
  );
}

Or, if the HOC was a render-prop thing, maybe this could work:

// page.tsx
function PostListRSC() {
  const postList = rscClient.post.list.fetch({});

  return (
    <Hydrated
      queryClient={rscClient.hydrate()}
      Component={PostList}
    />
  );
}

Then, the client could "just work" in a pre-hydrated way where we wouldn't need to pass initialData.

Overview of how to do it

• Create a new recursive proxy like the one we have in /@trpc
• Create new QueryClient() and populate it as we're calling (similar to our utils.*.fetch()

---

• Don't take the API design above as absolute truth, it's probable that it will have to be slightly different
• One important caveat is that we need to make sure this queryClient isn't used across multiple clients' requests.

Maybe we wanna use `use()`

Maybe we want to do

function MyComponent() {
  const post = use(trpc.post.byId({ id: "1"}))
  // [...]

In order to enable parallelization and using Promise.all, etc