Thank you!

Same, it's so good! Thanks for all the work here Jack, you're making us all better.

Thanks! Happy to have helped.

We are. Thank you for asking.

Agreed! I've just used it on a App dir/Drizzle/fetch setup and it worked quite well with handing types from server components to client

Same here, that awaited type is very useful. Thanks for the video Jack!

Is is working?

Thanks! Name is Jack though.

​@@jherrlol

tRPC has a utility type for this exact situation called inferRouterOutputs to retrieve the outputs of each endpoint

What issue are you referring to if you do not mind to share? Is there any particular Issue or Discussion opened?

@@YordisPrieto it’s about server component’s caching. Next team somehow decided a 30 seconds minimum caching for server components and revalidate value cannot change it. As far as I’m concerned it’s something similar to opcache of php. It’s mainly for html content inside of a server component but I noticed it also affects fetching as well. There was a discussion on github to provide a new global similar to revalidate in order to override caching time but it’s not implemented yet. That being said, mutations or refetching is not handled properly without additional methods like router.refresh() etc. and it complicates things. Many people had issues about this “cached by default” approach.

@@mertdr that explained what happened to me. Debugged for ours Nats message passing because I couldn’t figure out why my next page didn’t show the results… until I opened the console and forced the cache to be invalid … never understood the duck was going on until now … really stupid if you ask me

@@YordisPrieto I switched to TRPC the day I posted the comment above so I remember the actual problem vaguely. As far as I can remember router.refresh() didn't help to invalidate fetch calls in server component, which is a huge problem. Caching is vital part of applications but like you said cached by default approach is not sensible and brings more problems than it resolves. I got used to server/client components and enjoy the concept very much but there are still so many things to iron out.

I am also looking for some details about how to use context for implementing Clerk with TRPC in this setup

@@ovidiuk2 I'm getting closer. this works but always fails on auth right now. maybe it will help you solve it context.ts next to the trpc.ts file import * as trpcNext from '@trpc/server/adapters/next'; import { SignedInAuthObject, SignedOutAuthObject, getAuth, } from '@clerk/nextjs/server'; // import { FetchCreateContextFnOptions } from '@trpc/server/adapters/fetch'; import { inferAsyncReturnType } from '@trpc/server'; interface AuthContext { auth: SignedInAuthObject | SignedOutAuthObject; } export const createContextInner = async ({ auth }: AuthContext) => { return { auth, }; }; export const createContext = async ( opts: trpcNext.CreateNextContextOptions ) => { const context = await createContextInner({ auth: getAuth(opts.req) }); return context; }; export type Context = inferAsyncReturnType; update trpc.ts to import { TRPCError, initTRPC } from '@trpc/server'; import type { Context } from './context'; const t = initTRPC.context().create(); export const router = t.router; export const middleware = t.middleware; export const mergeRouters = t.mergeRouters; const isAuthed = t.middleware((opts) => { const { ctx } = opts; if (!ctx.auth?.user?.id) { throw new TRPCError({ code: 'UNAUTHORIZED' }); } return opts.next({ ctx: { user: ctx.auth.user, }, }); }); export const publicProcedure = t.procedure.use(isAuthed); change route.ts to import { NextRequest } from 'next/server'; /* eslint-disable @typescript-eslint/no-explicit-any */ import { appRouter } from '@/server'; import { fetchRequestHandler } from '@trpc/server/adapters/fetch'; import { getAuth } from '@clerk/nextjs/server'; const handler = (req: NextRequest) => fetchRequestHandler({ endpoint: '/api/trpc', req, router: appRouter, createContext: () => ({ auth: getAuth(req) }), }); export { handler as GET, handler as POST };

I got it fully working.. not sure if this is best practices or not but what I found is you can't pass the auth from clerk on the server fetch, but you don't need too cause your page should be auth'd too. So what I did was updated the context.ts file to handle no context from server by putting in a userId===system. /* eslint-disable @typescript-eslint/no-explicit-any */ import * as trpcNext from '@trpc/server/adapters/next'; import { getAuth } from '@clerk/nextjs/server'; // import { FetchCreateContextFnOptions } from '@trpc/server/adapters/fetch'; import { inferAsyncReturnType } from '@trpc/server'; export const createContextInner = (req: any) => { if (!req) { return { auth: { userId: 'system' } }; } return { auth: getAuth(req), }; }; export const createContext = async ( opts: trpcNext.CreateNextContextOptions ) => { const contextInner = createContextInner(opts.req); return { ...contextInner, req: opts.req, res: opts.res, }; }; export type Context = inferAsyncReturnType; then you modify the serverClient.ts to import { appRouter } from '@/server'; import { createContextInner } from '@/server/context'; export const serverClient = appRouter.createCaller( createContextInner(undefined) ); @jherr

Not sure the best approach for this but in my case I've created a createTRPCContext function that return my db object: export const createTRPCContext = () => { return { db, }; }; Then I used this in the init function: const t = initTRPC.context().create({ when creating the serverClient: export const serverClient = appRouter.createCaller(createTRPCContext()); and in the handler: const handler = (req: Request) => fetchRequestHandler({ endpoint: "/api/trpc", req, router: appRouter, createContext: createTRPCContext, }); For Clerk in your trpc file: const isAuthed = t.middleware(async ({ next }) => { const user = await currentUser(); if (!user) { throw new TRPCError({ code: "UNAUTHORIZED", message: "Not authenticated" }); } return next({ ctx: { user: user, }, }); }); export const protectedProcedure = t.procedure.use(isAuthed); Now your protected procedure are going to have user within the context

@@IcedTears thanks pal, thats exactly what I needed for clerk

Also the router caching problems tho

I don't. I'm now a full time content creator.

Should be pretty straightforward to swap out sqlite for Postgres. They are both SQL databases and in this simple usage context are essentially identical.

@@jherr ahhh yes, i had done it before i made the comment

When I do a video on a technology like tRPC, what I'm looking to do is to focus the content of the video on that topic. So in this case I want to show queries and mutations using tRPC to demonstrate tRPC. Is tRPC the right choice on the App Router? Totally up to you. But if you decide to use it, then you can use this video as a reference for that. It's not meant to indicate that in all circumnstances that tRPC is the correct choice architecturally. If you can get away with it, server actions are far easier.

TBH, I haven't tried multiple routers. Feel free to post an example of your code on the Blue Collar Coder discord and folks on there can have a look. Please read and follow the #rules before posting.

Server actions are alpha/experimental still. Plus, nextjs doesn‘t really promote fetching data in client components with server actions. I use RSC patterns in server components + tRPC in client components and it works wonders.

Maybe you're implying something about "fetching" data vs mutating data on the server, but as far as I can tell fetching data works fine.

@@asutula5797 it works, but nobody from Next.js promotes this solution in the docs and the caching story is unknown or even non existent.

@@filipjnc thanks, that does make sense