tRPC: Smart and Easy APIs
Вставка
- Опубліковано 9 чер 2024
- tRPC makes building APIs fast, easy and type-safe. If you want to try your hand at backend or full stack work, this is something you'll want to try out for yourself!
Code: github.com/jherr/trpc-intro
👉 I'm a host on the React Round-Up podcast: devchat.tv/podcasts/react-rou...
👉 Don't forget to subscribe to this channel for more updates: bit.ly/2E7drfJ
👉 Discord server signup: / discord
👉 VS Code theme and font? Night Wolf [black] and Operator Mono
👉 Terminal Theme and font? oh-my-posh with powerlevel10k_rainbow and SpaceMono NF
0:00 Introduction
0:46 tRPC/Express API + React Client Setup
3:26 Server Setup
4:17 Query Routes
6:06 CORS Setup
6:28 Exporting The TypeScript Types
7:16 Connecting The Client And Server Projects
8:03 Client Setup
10:34 Querying The Server
12:15 Building A Basic Chat System
12:50 Typing Route Inputs
13:39 Queries With Parameters
14:02 Adding A Mutation
14:37 Mutating From The Client Side
17:07 tRPC Subscriptions And NextJS
21:33 API Tech Comparision
25:05 Outroduction - Наука та технологія
This guy makes complex stuff so simple. What a great skill to have!
He’s got a great voice, could go into voice acting if he gets tired of software
11:05 - Out of the entire tutorial, as useful as it is... This is what I value the most. Being able to share the excitement of getting something to work when I barely know anything about it. Don't ever lose this energy Jack!
I really like how you teach different technologies and how excited you are to teach them. That’s really helping people getting involved! Keep up
I watched half a dozen videos today on this topic and this is the first one where I understood how to use it and where its trade-offs are. Great tutorial.
I wanted to get started with tRPC, and the first thing I did was check if you’ve made a video about it.
I love seeing that tRPC uses React Query. It deserves to be the standard for all React http requests.
Share the same opinion!
I agree! We been using trpc for over a year now with Prisma and next and we're hiring. Hit me up on Twitter if you keen to join
Thanks Jack. You saved me so much time by demystify the whole process, from setting up the development environment to wrapping up the project. Clean and effective code.
A few weeks ago I said you had a knack for dropping videos on exactly what I'm looking for.
And you've done it again!
Awesome stuff - been waiting for a good tPRC tutorial as I've seen a few devs use it
Wow! Amazing video, Jack! Thank you so much ❤
Ok a lot of awesome stuff, great examples, excited to discover you and subscribe, etc., but... that transition at 21:26! Had to back it up and rewatch that a couple times! Haha nice work
Cool stuff! Please keep making videos like these. Ps: The video quality is getting sooo much better these days.
Wow... how have I not heard of this channel until now? This is great. Thanks!
One of the best decisions I've made is subscribing to this channel. This guy is awesome!
Such a great walkthrough. Thank you!
Another fantastic video on new technology.
Perhaps in pros/cons, on backend side trpc is only nodejs unlike REST, GraphQL, gRPC supported in most programming languages. Apologies if I missed that in the video.
Really keen to try it out 🙂
Thanks jack !!! All your efforts are priceless ❤️
0:39 slick transition
love your vscode theme and font
Jack, amazing content and great presentation. Thank you for covering the frontier of dev tools. A quck question: is there any materials in which you explain how to setup concurrently, wsrun and how to handle errors caused by these tools?
OOOKAY! Those transitions are cool
Thanks for the vid, @jack.
You are my fav. channel for getting react ecosystem news :D When you make a video about it, its about time to put it on the radar.
Great love it! Reminds me a bit of my WCF adventures back in the days where I could just import a wsdl file (versioned) on the client and I had the models and type safety setup within a breeze. ❤️ This comes really close. 👍🏻
I do not have fond memories of wsdl. In general, a workflow that requires a bunch of code generation eventually runs into synchronization issues unless there's a lot of discipline (or it's just a single developer).
Not saying it doesn't have its place (in C# I'm find of linq2db with T4 templating), but I think sharing types between client and server without code generation is better than wsdl.
...Well, after accounting for everything you lose by not being in a strongly typed environment.
@@DanKaschel yes exactly it is nice when there are not a lot of devs involved. It works nicely in rapid development cases.
These new transitions are 🔥
Thanks a lot, man! You do great!
Hope you can make a video that shows a production example of using rabbitmq or queues in the wild with a react app. Thanks for the awesome content!
great tutorial. thank you!
I didn't know anything about tRPC and this video explained it so well. Also, it wasn't boring at all. Thanks for the video!
A-mazing content! I'm trying out the T3 stack and your video is incredibly helpful to understand trpc!
question, shouldn't the onAdd query be auto invalidated because it suffered a mutation? I feel like forcing invalidation in the onSuccess callback shouldn't be necessary
Hell yeah man good work
Really awesome explanation
What a cozy house I love that forest view
So helpful! Thank you
Great as always
Excellent and clearly explained. Trpc's advantage seems to be in its simplicity and speed in terms of design. As long as you're in a monorepo and are using typescript, I think it's a great option.
Great video, nice and clear thanks ❤
I feel like you undersold the benefits of that e2e typesafety a bit
1 other downside to tRPC compared to REST/GraphQL/gRPC that you didn't mention is that unlike those others tRPC is only useful if both your FE & BE are TypeScript. Technically it probably also works with a JS frontend, but you'd lose the main benefit
I'm really glad I stumbled on your channel, lots of great content I can share with team mates
I would say that tRPC is no worse than REST in that situation. gRPC is kind of a different story altogether because protos define everything and you can't get around the protos. GQL is different again in that there is runtime introspection, which neither REST nor tRPC (or gRPC) have.
Anyway, I think tRPC is a no downsides upgrade on REST, but tRPC vs GQL or tRPC vs gRPC is a different story.
Very intersting. Thanks.
You're awesome Jack!!!
One of the best ways to build apis wow can't imagine takes all the work using traditional rest APIS
Thanks for monorepo. I didn’t know how to link those without npm link command
Thanks very interesting ! Really thinking about how it could compete with GQL ❤️
Awesome and clear! Please make a tutorial of how to
implement tRPC with nextjs 13 app directly
Great video! I'm curious, what software/hardware are you using for the on screen annotations with a stylus/pen? It's so seamless!
ScreenFlow plus a commodity drawing tablet from Gaomon.
I personally use apollo client with graphql, I have the same features but trpc is also really interesting.
Thanks, Jack
It looks a lot like how we make graphql servers.
What do you think would be better trpc or graphql server if we know graphql, as we can use the graphql schema to generate type safe code on the client using packages like graphql-code-gen
Niceee!
Thanks, Jack for the always awesome video. Can we get a video on utilizing the workers in browser to at the best extent possible to get performance.
Definitely thinking about that one.
Thanks 🐐
Thanks!
Hi Jack or anyone that knows, what tool do you use to have the nice graphics with the apple logo and node version? Is it a oh-my-zsh plugin?
Hey really cool vid as usual. I'm picking some new stuff thanks to you. I have two question:s I see that you use ScreenFlow and I like the effects. Any resources to look at to learn more? I want to make nice videos as well. And what do you use to draw on the screen? I saw you were looking down while doing that. Thanks!
For drawing i use a Gaomon tablet and Screenbrush. I do all the code work in Screenflow then use After Effects to put it all toghether.
@@jherr thank you!
Very neat Jack, for those who don't want to expose graphql, is tRPC a good practice to wrap or hide graphql data source ?
Yep. IMHO, GraphQL is a good fit for when you have a lot of flexibility on the frontend and the structure of queries may change a lot, or if you are providing a customer API (though that has some issues as well). If you don't fit either of those then something like tRPC is fine because you know the data you need at build time.
Please, when u did npx create-react-app, it showed a bunch of option to select such as if u wanna use css or tailwind
How do i get that to work on my pc as well?
You should check out Telefunc. It's similar to tRPC but has a more ergonomic api. IMHO
Great video as always! I learned something new every time and trpc is so cool! I've always found sharing types with the front and back end such a pain. Not to pick nits though: isn't it the browser that enforces CORS? That's a security mechanism that always mystified me...
Yeah, CORS is only required for CSR.
The browser enforces requirements established by the API. CORS is the mechanism that allows an API to say it's okay with requests from other origins.
@@DanKaschel I wasn't really confused by how it worked, just that it's so easy to write a proxy that enforces a different set of CORS rules, makes that protection useless against all but the least savvy would be API theives. I'd be happy to learn otherwise...
@@jasonthorpe3470 an important feature of cors is to protect requests using cookies. If you create a proxy you will have a different origin so the browser won't send the same cookies. If the api doesn't use cookies, then there isn't much security benefit to cors
Hey Jack, this video is really helpful and has gotten me more interested in tRPC and typescript. One small thing that left me a little confused is that when you connected the api-server with the client, while this works for the dev process, how would this pan out during deployment? The client would not be able to access the api-server package as it only exists in the local env... Would adding the server as a dev dependency yield the same result?
Very good question. You not actually importing any code between the 2 apps. Your simply importing types. In production the types are compiled away. Under the hood trpc makes an http call with the route names. So it's not like the files need to be collocated at all.
Ps. We been using trpc for over a year now with Prisma and next and we're hiring. Hit me up on Twitter if you keen to join
Wow this is like prisma but from frontend to backend or cross service calls. Basically remove contract testing.
Can you give some tutorial how to style fonts the way they look in your IDE? Also, what's the name of your theme?
Just FYI: The NPM package for create-mf-app doesn't link to the Github repo
Some examples are using monorepo , right? How can I use it with different repos for front and backend ? Do the app like package ?
Hi Jack! I'm new to backend development, what do you mean at 22:10, when you talk about "adding a reporting mechanism on top of REST"? thanks!
REST is an entity based model. Your model entities like user, product, and order. You can read, write, update and delete individual entities, and also get lists of that type of entity (e.g. all products.) But you can't get a joined set of entities in that model, for example, all the users that placed orders for a give product. That's why people created a REST API and then bolted on a set of reporting APIs to make up for the limitations of the REST API.
@@jherr got it! 😁thank you for your awesome channel
How would this work if the API source is in a completely different repo? What if the API is running and hosted on a different server from where the UI static files are served?
You'd generate into a shared npm module, or generate into the server module and have the client app consume whichever shared module you created.
How do you setup ur terminal to give you all those pretty icons
Hey Jack!
I'm curious about creating the trpcClient as state here. Why would this be required as opposed to, for example, useCallback? Would this still work? Can you think of any reason to prefer one over the other?
Can you give me a time reference?
@@jherr sure thing! 9:54 should do the trick - sorry that'd have been pertinent considering this is from Feb!
@@mmmike3426 Well, it's not a function, so I wouldn't use `useCallback` but you could use `useMemo` if you want instead, though as some folks have said the docs state that in the future React reserves the right to flush memos to recover space. Or you could use a `useRef` for this, but then you'd need to say `trpcClient.current`, which is not exactly a game changer.
Frankly you could probably just pull this out of the component altogether and just define it at the top of the file. I'm not 100% sure why I found it necessary to define it in the component here. As you say, it has been a while since I did this video.
Lots of interest in TRPC tho!
@@jherr ah of course - it's the return of the function that we care about. Oddly enough, I'd thought about whether it *might* need to be invoked inside the component if it was relying on hooks somewhere in there. I feel as though, if that works, it'd be the simplest/cleanest option, as it'd be colocated with the RQ client? I'm gonna give this a bash and see!
Thanks for taking the time to respond, really appreciate it!
Awesome content
Can you share your vs code theme?
Thanks Jack. It's a great video. One thing that I need to know is that tRPC can run at the Edge like in Cloudflare Workers, Deno Deploy, Fastly Compute@Edge, others...
Recently I have started using Cloudflare Workers with Solid Start (The Awesome Solid.js Meta Framework) & Deno Deploy with Oak & Faunadb. as a result, the whole thing is fast. Building API's & SSR (with HTML Streaming) at the Edge is Really Awesome 👍😎.
I honestly don't know. You'd have to ask the tRPC author on that one. :)
I love you give the github repo. There is alot to like about the trpc, fresh, deno stack. So moving my stuff over. Keep running into small issues, like do i need a mono for trpc etc. Love more on this stack together. Also what scales better gql or trcp for request etc? Or should i just go server api. We always talk about developer happiness. But i want whats best for my consumer.
What scales best... Depends on what scales means to you. In terms of load I think tRPC scales better because the per-transaction costs aren't as high. IMHO, if you are offering API as as service, then go with GraphQL, if you are building both the server and the client, use tRPC.
very kool
can someone tell me what kind of extension is in the video which shows the text autocomplete highlights in the editor as we type.
Github Copilot
you are doing great
Apparently that router method at 3:55 is deprecated now? Not sure if its gonna break my server or not but we'll see!
What fish shell theme are you using?
When he installed dependencies with "yarn", why were there no node_modules created in client and api-server
hey can you tell me the VS code theme you use? Thanks! Great video.
Night Wolf [black] and Operator Mono or JETBrains Mono.
i notice a lot of hype about trpc lately but i havent figured out and havent tried it myself yet. is this also beneficial for java backends ? i have very limited fullstack experience and dont know what server this is supporting
No, this wouldn't benefit the Java backend world. The idea here is that tRPC is TypeScript on both ends of the pipe, so it makes it easy to define your object types once and use them in both places.
Thanks Jack! I have my cross feelings about TRPC. Why would anyone would like to make a non-language agnostic API? So if I'm a python dev, I will have to first learn TS and then TRPC to consume the API?
It can be accessed just like any other REST API. It's just easier when you use TypeScript.
Hy Jack, Excellent content as always, but I'm always wondering what is your opinion on NodeRed low-code, because I'm amaze with how NodeRed handle business-flow. can you give me one or two opinions on this. thanks so much Sensei.. 🥳
Would love to see example without anything react and just tRPC on it's own, the most vanilla possible experience.
Well another Con agains GraphQL is that it can't choose what it will be sent to the client, cause in tRPC, what you have on your query is what is going to be sent, right?
You mean a con against tRPC right? Yeah, that's correct, the payload is the payload.
How did you make the terminal like that?
so TRPC is Graphql without the additional syntax learning?
You can also get your types from Graphql server to the client
You'll have to add a type generation build step for GraphQL though, while tRPC seem to be able to infer the types directly.
I'm love with this terminal theme. Is this a zsh theme?
Nope, it's oh-my-posh.
@@jherr what theme is this?
@@jeielmosi Night Wolf [black] and Operator Mono.
I’m tryna transition from fastAPI to gRPC, is there a fundamental difference between the two as to why you’d pick tRPC?
Are you talking about the Python fastAPI? If so, then, a big difference would be Node vs Python.
It is like reading Dostoyevsky and then trying to pick up a pen and write watching you
What’s that terminal theme you use. I like that it shows you the full path.
Night Wolf [black] and Operator Mono.
@@jherr and how do you get your ZSH terminal to show you the full path
@@rcarias78 oh-my-zsh probably
Reminds me of FeathersJS and Meteor.
Please - what is your extension for terminal - so it looks cool!?
Fig is what I think you are looking for.
I kind of get the same feeling that I got when I first saw Redux. I was in awe when I saw the time-travelling feature, but I couldn't help but thinking that it was kind of cumbersome to set-up for the value. Maybe they'll improve the API or the general DX in future releases.
All in all, I'm not sure to get the full value of tRPC? Maybe I was so hyped before reaching this video, with so many people singing it's wonders of and swearing by it, that it was easy to feel kind of disappointed.
What font do you use in terminal?
SpaceMono NF
Can we use ionic with backend express trpc?
I don't see why not.
Could you please update this video using tRPC V10? Thank so much for your valuable videos!
- error
```
Error: Debug Failure. False expression: Non-string value passed to `ts.resolveTypeReferenceDirective`, likely by a wrapping package working with an outdated `resolveTypeReferenceDirectives` signature. This is probably not a problem in TS itself.
```
- solution: upgrade version in package.json like below
```
"ts-node": "^10.8.0",
"ts-node-dev": "^2.0.0",
"typescript": "^4.6.4"
```
How do you type so quick, what vscode plugin you use?
GitHub Copilot?
how to deploy this project to vercel?
Wundergraph like
tRPC is great but there seem to be a lot of unnecessary complexities. Telefunc is probably a more literal RPC. Would be fun and helpful to see you try it.
I wonder why devs decided to create a trpcClient with useState hook. Why not just create it the same way as react query client... I checked tRCP docs, I don't know. I checked your code as changed it, nothing broke, everything still works. Feels like trap, but I think it should be just fine, at least in this case. Maybe it has something to do with async stuff and the new React use hook , I don't know
With HTTP2 and the rise of DaaS I do wonder if the value of websockets is as high or broadly useful as it once was. It feels like web sockets is possibly better for niche situations nowadays
I am trying to see how tRPC is different from the regular REST API, and it seems it is nothing different from REST except the name.
It depends on what. you mean by REST. REST isn't a standard. It's an "architectural style". And the only specific thing it covers is the basic verbs associated with entities and collections and the hierarchal relationship between them.
Generally speaking REST is both incomplete in that it doesn't allow for one query that involve more than one entity or collection at a time, and also incorrectly structured because the hierarchy of the entities doesn't allow for important permutations of queries.
I usually see REST coupled with a set of RPC endpoints. And people just call that "REST" when it's not really anything "standard". Every team/project/company just comes up with their own standards.
tRPC is a standard (though not as well specified as GraphQL) and it provides easy end-to-end typing.
@@jherr What I mean is that the things you did in the video, seems like I can do all of them with bare ExpressJS with the same amount of effort, and probably even less amount of code. That's what I am not sure why I need tRPC for my project.
@@ziranshuzhang6831 You might not. If you don't think that tRPC adds anything then don't use it.