Learn tRPC in 5 minutes

[@tenthlegionstudios1343]

Such a clean and simple way of explaining zod and trpc. I listened to your typescript debate and learned you were once a teacher! Definitely your calling in life. I have not seen such a good explanation/example of zod trpc. And the transition to trpc without zod to with zod really made things click for me. Thanks Matt!

[@miklschmidt]

tRPC is amazing. It's hard to overestimate the value of end to end typesafety, it's such a pleasant way to do fullstack development. Cannot recommend it enough! Just wish there was a native way to do SSE, that would be cool!

[@WZLR]

I know it's not necessarily SSE but have you taken a look at the subscriptions API on tRPC?

[@miklschmidt]

@@WZLR I have yes, but it's not really what i want :) I want an endpoint that can return a stream. Building it for websockets is kinda messy, but doable.

[@EddyVinck]

Server-side encryption?

[@miklschmidt]

@@EddyVinck server-sent events.

[@EddyVinck]

@@miklschmidt ah okay, I’ve been studying for my AWS exam and they use the same acronym

[@saurabh75prakash]

Really love these short videos explaining the core concepts. Thanks Matt!

[@helleye311]

Lovely intro to tRPC. It really feels great to have autocomplete carry you through the entire api call, not to mention the fact it runs on react-query, so you get query invalidation, pagination and all that great stuff for free without any setup (besides the initial boilerplate, but that's one-and-done). You really can just not have any defined types in the app and still get the full benefits of typescript, especially if you use an ORM of some kind. If I have at least some control over the tech stack, I simply refuse to work without tRPC.

[@StephenRayner]

I was just typing tprc with zod into the search bar 3:42. Decent videos keep it up!

[@juliusmarminge]

Awesome video Matt. You really covered a lot in just the right detail for an introduction video! ❤❤

[@markushansson1634]

I love how it integrates react-query into it. I wish I could use it as some kind of anti corruption layer against a rest api. Often I dont control the backend but get available rest endpoints to use. I want to be able to fetch against an endpoint in a query procedure, transform/map it to what the client wants and return it.

[@PlerbyMcFlerb]

zod on its own is great for this

[@nark4837]

I like the power of this, pretty cool. Things like this exist that could be language agnostic, unfortunately code-generation is ultimately required for that, so I like that tRPC does not require code-generation, even though it is only for TypeScript, that is a worthwhile trade-off. The way it forces you to only send the type expected on the server is great, meaning we can only really abuse it by manually requesting our backend server, and even then, because we do runtime type validation using Zod (or however we like), this is also prevented! Awesome!😄

[@codewithfongoh]

Thank you so much, you just saved me from a gazillion years of confusion.

[@monstajoedev]

tRPC is incredible I actually made a video with the T3 stack and I love the autocomplete that comes as a result of this type safety

[@matheusnogueira7219]

this was the one that made tRPC click for me. thanks a lot

[@BoudewijnDanser]

Renewing my subscription to your face! Keep up the great content. 🙂

[@SuperYoda7]

You made it so clear, thanks for that! I am new to this and was so confused ! I left with a big thumbs up and subscribed!

[@Vantivify]

Would be cool if you could make a showcase for such setup. Client/server workspaces with react vite trpc + production build🎉

[@bopon4090]

Okay im adding this to my project

[@screemoh]

Nice and concise video - excellent !

[@extrordinaire3725]

Awesome video! tRPC seems quite amazing.

[@roni_castro]

The only problem is that in most projects the backend is separated from frontend, so tRPC could be created only as a BFF

[@judegao7766]

So I’d only use it for my personal project

[@gorovlib]

If you are working on enterprise backend focused software, tRPC is really useful only for BFF, but in other cases usability of tRPC depends not on architecture of software but on the way you organize code base and pipelines. For example in mono repo it con be useful even if backend and front-end is separated

[@hasifzulkifli5416]

What is bff?

[@gorovlib]

@@hasifzulkifli5416 backend for frontend

[@PatricioHondagneuRoig]

​@@hasifzulkifli5416 back-end for front-end

[@AmanMavi1]

I am a frontend developer and I have faced problems because key name was different in database and i spelled it differently in frontend. This will help to avoid those mistakes.

[@pablomayobre]

Every time I see tRPC + Next I immediately think they achieve the same thing as Remix does, but a bit less elegant and integrated. But then again Remix is not always the way to go so having more options is great!

[@t3dotgg]

I promise you tRPC is much more elegant once you have it in your editor. Remix code snippets look nicer but when you start moving things around you’ll realize how fragile code is without real typesafety

[@shapelessed]

The concept seems a lot like what SvelteKit does. Basically a tight abstraction and type safety on both ends.

[@mattpocockuk]

Exactly! Great for when you don't have framework support (i.e. RSC) for this sort of thing.

[@isaacfink123]

How does sveltekit do that? Sveltekit has two ways of calling server side code api routes, and form actions, and none of those are typed

[@shapelessed]

@@isaacfink123 I'd suggest looking into it more closely. It's really tightly integrated once you know how to leverage it. It just doesn't force you into much things from the get go.

[@sagnikbhattacharjee3410]

Amazing explanation

[@27sosite73]

short and sweet ty mate

[@potloodgum]

Thanks for the great explanation!

[@ozzyfromspace]

Nice video! I wish go devs had something like this. At my startup, the frontend is nextJS but our backend is a gin server (we're doing a lot of streaming IO stuff, so go was a good fit). Petition for someone to build go-rpc lol 😂

[@leo11877]

Does the frontend project (say React) and backend (say NestJS) need to be in a mono repo so that the types are easily reflected between the 2 separate projects?

[@mattpocockuk]

Yes!

[@complexity5545]

Good video. I learned alot. This is more for JS^TS heavy devs (like reactjs).

[@otmanm4095]

Great!

[@carlosricardoziegler2650]

Really nice video what is your “better” approach to create api services ? Express ? Fastfy ? Trpc ? Only for backends :) Thanks for some advice

[@KMoscRD]

Hi, thanks for amazing explanation.

[@dechobarca]

Web Dev Simplified: Learn tRPC in 45 minutes. Matt Pockock: Learn tRPC in 5 minutes. Think I'm gonna wait until someone teaches me how to use it in under a minute before trying tRPC :D

[@lukasmolcic5143]

kzbin.info/www/bejne/ZnXccqyCmbuKZqs would a 100 seconds be enough? :D

[@dechobarca]

@@lukasmolcic5143 Too long mate.

[@pablom2274]

Thanks for this! I'm trying to learn trpc and this helped a lot to understand the basics!. Btw I'm curious, do you init a project in the root folder? do you just push all to github then? (let's say for uploading everything to a cloud server).

[@antonpieper]

What are your thoughts on TypeBox? It is similar to zod, however it builds straight JSON schemas and only validates data (does not parse or transform).

[@ViniciusdosSantos-y2d]

Amazing!!!

[@dinoscheidt]

0:10 really cool framework for building *SMALL CRUD* fullstack applications - everyone else should continue focusing on interface / data model first design so feature and service teams can keep working in parallel

[@mattpocockuk]

If you're owning the frontend AND backend, then tRPC can scale all the way up to a large app. I don't think size is the right delimiter, but whether or not you own the WHOLE stack. If you only own part of the stack, you can't use tRPC.

[@jeromealtariba7339]

agree. Wondering how efficient is this stuff for non monorepos projects... The way to share the server type is unclear... Better to work with graphQl probably

[@lukasmolcic5143]

@@jeromealtariba7339 this is intended for monorepos exclusively

[@justine_chang39]

Love the video! How would you recommend I handle auth if I'm using NextAuth, Prisma, tRPC + Express on an external API?

[@michaelcarneal7573]

I have been curious on how tRPC interacts with micro services. For example if I have a Client API gateway Books service Authors service Basic example of a Back End For Frontend, where tRPC would take the place of the api gateway. My question is, is that I cannot find any examples of tRPC connecting to another service, either by http, an event, or a message, would that suggest that this is not the most ideal implementation for the use case of an api gateway

[@mattpocockuk]

tRPC creates a typed RPC - i.e. a tight coupling between a client and server. It's not good for making arbitrary fetch requests - use fetch for that.

[@akhil1996kc]

How would this work if we do not want front end and back end in the same repo?

[@mattpocockuk]

It wouldn't!

[@inversemetric]

Major gripes about trpc - it doesn't support binary, and it uses query strings to send data over the wire. Those are both deal breakers to me.

[@wlockuz4467]

Is tRPC a networking library or is it a full fledged server framework?

[@eindbaas]

it's an alternative to REST and GraphQL

[@vitriowibisono2875]

Im still confuse what if the client and server are separately located in different machine. How trpc bridge the client-server call

[@mattpocockuk]

The server.ts files are deployed on a server. The client is deployed on a frontend client. The TRPC client uses the network to bridge the client and server.

[@priceless5386]

tRPC seems great, however, it is a little unclear to me where it will fit in with frameworks like nextjs, sveltekit, solid start, etc which are now allowing you to call server functions on the client, which give you that same type safety. Maybe I am missing something though?

[@mattpocockuk]

Yep, that kind of compiler magic, if you want it, would replace the need for tRPC. I'm not yet convinced about the whole 'call the server from the backend' - it feels a bit too magical. Having separate files that you can go-to-definition between is best, because the separation is clear. BUT - I could be convinced otherwise, haven't had a chance to play with it yet.

[@adrianbarbic3315]

@@mattpocockuk did you mean to say call the server from the ‘frontend’ here?

[@mattpocockuk]

@@adrianbarbic3315 Yes!

[@6365bharath]

I'm not convinced with frameworks like trpc, nextjs etc. Firstly, trpc doesn't integrate well with existing react frameworks like Next. Secondly, in the world of microservices there's no guarantee that people are using Nodejs on the backend nor that every service will be a monolith. Now coming to Nextjs, I still have huge concerns as to how Server side rendering scales with a lot of traffic. It's a cpu intensive task and will block NodeJs event loop. So if SEO is not a huge deal, I would still prefer CRA with good lazy loading techniques.

[@MrTrickydisco]

Nice Cravate!

[@MrTrickydisco]

Sorry scarf 😁

[@mattpocockuk]

@@MrTrickydisco Heh - I wish I could pull off a cravate with a t-shirt. That's a strong statement.

[@danielbark]

After making my tRPC tutorial i started thinking about how tRPC will live together with server components. I does not seem to be on the roadmap yet. Seems like they will need to support "tPC" 😅 from server components as well pretty soon? Do you have any thoughts Matt?

[@mattpocockuk]

Server components are async, so it should just work with await client.whatever.query()

[@Billiam112]

For the ones interested in the t3 stack, Daniel Bark ☝ has one of the best tutorials on YT on the topic.👌

[@danielbark]

@@mattpocockuk I think the client uses context and maybe other client side only functionality. So trpc would need to export another “client” suitable for SSR in that case I think.

[@m3a5x]

Did you check Zodios ? It’s like Trpc but schéma declaration use zod.

[@eindbaas]

Zodios is a toolbox for REST APIs, using Zod. tRPC is an alternative to REST. You can still use Zod with tRPC.

[@MrAtomUniverse]

I would like to click on a link and go onto a page/item/[slug] how do i go about that with trpc?

[@dexterous7516]

Is it possible to use tRPC in a non-monrepo project ?

[@_sjoe]

Nope

[@mattpocockuk]

You can use it on projects where you have backend and frontend in the same package.json, like in a next.js project. But I think the spirit of your question is "does the backend and frontend need to be in the same repo to use tRPC" - the answer is yes.

[@siya.abc123]

I wish this together with next-auth was available on react-native. I would put in tickets to refactor my code base this very moment

[@mattpocockuk]

This works great on React Native!

[@codernerd7076]

If you don't know how to do Auth without next-auth you really need to learn that... like it's one of the more important features of any modem app!

[@mattpocockuk]

@@codernerd7076 I don't think that was implied by their comment.

[@nyambe]

Doesn't Nuxt 3 do something like this? As a Vue developer what advantages do you get with tRPC

[@AugusDogus]

👏👏👏

[@I-just-hold-white-paper-up]

omgit is like the old GWT framework

[@Ayoubased]

I didnt understand the video at all idk why. what are the prerequisit

[@ДаниилБеляк-щ2н]

Now imagine your manager say: “alright team, now we gonna make an Java android app. It would be using the backend we already have” and you doomed

[@mattpocockuk]

github.com/jlalmes/trpc-openapi

[@drizzletone9148]

But how to use it if you have let's say 50 endpoints? What's the best elegant way to separate them and not get lost in huge TRPC router file?

[@mattpocockuk]

You can separate the files and merge them later

[@smash3689]

This is probably a very noob question, but in 1:00, how the exported type "AppRouter" can be derived from the variable "appRouter" when it's not yet initialized?

[@binitrupakheti4246]

Hoisting

[@smash3689]

​​@@binitrupakheti4246 thanks for the answer, but any variables that are declared with "const" or "let" would've thrown error if the "hoisting" rule were to be applied. in this case it's not throwing error because "export" doesn' follow the usual "TDZ" rule, which is something i googled and learned after watching this video.

[@wickedjutto]

Does it work for a React Native or other JavaScript based mobile frameworks?

[@mattpocockuk]

Yep! Works anywhere JS works.

[@markoffden]

Everytime I see Remix doc examples with Prisma calls to db along with UI components, or such examples of both front and back code sharing types in one repo, something clicks in my mind that this will never be a real world project scenario. Yeah, I know Google is monorepo, but still…

[@lukasmolcic5143]

how good is tRPC for working with web sockets?

[@Euquila]

I believe tRPC is an API for HTTP requests, not for web sockets

[@PiotrNalepa]

It's only for NodeJS backend development, right? If I have backend written in other languages it won't work, am I correct?

[@wlockuz4467]

You should look into the OpenAPI standard if you have backend and frontend written in different languages.

[@mattpocockuk]

Correct!

[@recklessroges]

Sounds nice for small toybox application. It violates separation of concerns. "Just because you /can/ doesn't mean you should."

[@dimitro.cardellini]

oh, no, no, no, and one more time no,... It is a very impure approach, when code goes before the contract. The first and obvious con is that you can't develop FE and BE in parallel. The last one is a pain on migration from trpc. So, if you agree to follow DIP (from SOLID), you must agree to avoid code-first practices for the cross-system interaction. With trpc we have interface owned by the server not by the client. in this sense I'd like GraphQL, when you can have schema separately from the server and client and generate types automatically for server resolvers and client mutations directly on the correspondent projects. trpc goes wrong way. The good way is to describe schema generate types and then use these types on the client and server side to get type safity.

[@ColinRichardson]

So... how does input know to call the z.abc.parse() function?

[@mattpocockuk]

It either takes in { parse: (input: unknown) => T } | (input: unknown) => T

[@ColinRichardson]

Ahh, that makes sense.. It's like it was designed for Zod then.. Though I guess it wouldn't have been so hard to make an adapter like (zt: ZodType) => ((input: unknown) => zt.parse(input));

[@weirdwordcombo]

Is it not incorrect for a client project to depend on a backend project? I guess that could cause lots of trouble with subsequent imports of modules that are foreign to a browser environment (database stuff, environment variables, etc, etc.). This is why I always introduce a "common" project.

[@mattpocockuk]

Note the use of 'import type' - that means only the type is imported!

[@ilijanl]

@@mattpocockuk Say you have monorepo with server and frontend as apps, it means that frontend needs to have at least server as dev dependency to be able to import the type. Is this correct or are there any other options (typescript projects/refrences?)? And how would you deal with it when server & frontend live in different repos?

[@mattpocockuk]

@@ilijanl Yep, this makes sense conceptually because your frontend is always coupled to your backend to some extent. You can't use tRPC effectively if your server and frontend live in different repos.

[@ilijanl]

@@mattpocockuk it is a shame because in my opinion trpc can be greater/more adaptable if you can define procedures and routes without giving the implementation. Those definitions can then be used to implement the router on the server and to infer the types on the client. Therefore the client won't need to depend on the server. And the extra is that you can reuse the validation logic on cliënt as well

[@Rundik]

The fact that it's snowing outside doesn't explain why you're wearing a scarf at home

[@mattpocockuk]

It's... cold?

[@raqueebuddinaziz]

why the void keyword before main() call?

[@mattpocockuk]

Not sure!

[@John-mj1kk]

It's used to specify that you are ignoring the return of main. Since main is an async function, meaning that you can await or chain .then(), there are times when you don't want to handle what the async function is returning, but rather just let it execute. In that case, it's good practice to mark it void to indicate that you will not be awaiting or chaining the async function as you don't need the result of it.

[@ToukiMS]

Is it me or it s not possible to intégrante trpc to existent projects ?

[@mattpocockuk]

Yep, it absolutely is possible. tRPC only needs one endpoint, just put it on an endpoint somewhere. Eventually, migrate all calls over to it.

[@AmodShindeDev]

Subhash Chandra Bose

[@george_davituri]

tRPC !

[@Brunoenribeiro]

so... where's theo? 😝

[@f0ssig]

http cache????

[@ko-Daegu]

this looks ans sounds anti-scalability and everything the microservices revolution brought to this field I'm confused how is this usfull for any mid-size project and above where we have microservices that speaks to each other via msgs (ex. RabbitMQ) and the front-end that hots a microservice endpoint that aggregate all these msgs how could this work beside a prototype or a tiny self project made in a weekend

[@grimonce]

And I've used rabbitmq for so long....

[@florianbopp187]

Very interesting topic, especially having watched the video about codegen. Any thoughts on gRPC as FE BE communication tool? I just watched a conference talk (kzbin.info/www/bejne/roXFY5Juj7GficU) by Dimitri Mitropoulos about this and it sounded quite interesting, especially since it would allow for non TS backends and non monorepos.

[@MrREALball]

One question: what the heck is a rooter?

[@mattpocockuk]

The King's Router

[@ColinRichardson]

Rou, like Roulade or Roulette, or Routine... Do you guys say R-out-tine?

[@dbred67]

Interesting, but not sure the extra abstraction and the benefits it brings is worth the occasional issue it solves.

[@mattpocockuk]

Yes, it's definitely abstract and relatively concept-heavy. But I actually think it makes for extremely maintainable systems and helps you work VERY fast.

[@dbred67]

@@mattpocockuk Not sure you are working faster if you account for all the setup and updating that needs to be done. Like you said towards the end might make sense for projects that contain frontend and backend code but for anything moderately large / complex you will quickly be using API's you don't control.

[@dbred67]

@@mattpocockuk btw - like the content you are doing, just the right amount of detail to explain the concepts. Intend to buy the typescript course to take my skills to the next level when I can block out some time to watch.

[@mattpocockuk]

@@dbred67 Yep, for many projects this won't work - but for the ones where you own the frontend and _at least part_ of the backend, tRPC is awesome.

[@chrisalexthomas]

/sings it's getting hot in here, so show me all your codes....

[@mediocreTyler]

Rooter

[@chrisalexthomas]

lol @face you can subscribe to here

[@hakuna_matata_hakuna]

pass , just use RSC

[@abdullahislam]

More confused after watching this video

[@Ihatebrexit]

This looks like it handles the stuff that irritates me most about graphQL... nice :)