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

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!

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!

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

Nice and concise video - excellent !

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.

Awesome video! tRPC seems quite amazing.

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

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!😄

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

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

Thanks for the great explanation!

Amazing explanation

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

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

short and sweet ty mate

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).

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.

@slimbofat

Жыл бұрын

zod on its own is great for this

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

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

Hi, thanks for amazing explanation.

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

Okay im adding this to my project

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).

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

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 😂

Amazing!!!

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

Great!

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

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

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!

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.

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.

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

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.

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.

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

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.

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!

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.

👏👏👏

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

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

@mattpocockuk

Жыл бұрын

Yep! Works anywhere JS works.

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.

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.

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.

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

@eindbaas

Жыл бұрын

it's an alternative to REST and GraphQL

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));

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

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

@mattpocockuk

Жыл бұрын

It wouldn't!

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

how good is tRPC for working with web sockets?

@Euquila

Жыл бұрын

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

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.

But we still have to map it to our own interfaces no? Say my endpoint returns an object there’s no type definition for the object I can define a component prop with right? I.e the response types are not named interfaces

@mattpocockuk

Жыл бұрын

You can derive your own types from the zod schemas - better than maintaining a separate set of interfaces.

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.

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.

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

Жыл бұрын

kzread.info/dash/bejne/Ynito9uFlLm9YKw.html would a 100 seconds be enough? :D

@dechobarca

Жыл бұрын

@@lukasmolcic5143 Too long mate.

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

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.

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

omgit is like the old GWT framework

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.

tRPC !

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…

http cache????

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

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

10 ай бұрын

github.com/jlalmes/trpc-openapi

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.

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 (kzread.info/dash/bejne/qoiWlMFxiq_Sg8Y.html) by Dimitri Mitropoulos about this and it sounded quite interesting, especially since it would allow for non TS backends and non monorepos.

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

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

@mattpocockuk

Жыл бұрын

It's... cold?

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.

@davidbroadhurst8107

Жыл бұрын

@@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.

@davidbroadhurst8107

Жыл бұрын

@@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

Жыл бұрын

@@davidbroadhurst8107 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.

so... where's theo? 😝

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

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?

Subhash Chandra Bose

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

lol @face you can subscribe to here

pass , just use RSC

Rooter

More confused after watching this video