Thanks for this great video Theo, this has answered a lot of my questions and really breaks down the unknowns and presents them in an easy to understand way!

I've used GrapHQL a lot of the last 4ish years and I still love using it, although, in a lot of ways, tRPC is what I hoped GraphQL would be.

I watch your live streams, and I enjoy re-watching the cuts you post. Your content is pure gold! Thanks for everything.

Love your content! I've used GQL only twice and I feel like I can agree with "REST with more steps" I'm going to try tRPC after I graduate from bootcamp. The bootcamp I'm in requires us to use Rails as our backend

Probably tRPC is the future, because it’s great, but at the moment GraphQL is more in demand by companies, looking at the job offers. For the moment it is "worthwhile" to learn GraphQL first and well, then tRPC ✌🏻

A lot of the time people think that graphql is going to automatically improve the performance. Graphql is what you described, 'schema' language. If you use graphql as a backend for frontend your graphql becomes extremely chatty. We had issues with port exhaustion after we deployed the graphql server as a serverless function. Graphql only improves performance if you design nested schema efficiently

As a one man team I've been using graphql because it saved me time when coding on the frontend because of the sheer flexibility. While I also lost 50x more time while implementing graphql on the backend properly with loaders and per field authentication.

I've used GQL with federation for 2 years now. It feels nice to be able to create super flexible queries that fetch data from many different microservices with one query from frontend. Would love to see some more complex examples of tRPC to understand why it's good and what it's advantages are over GQL. My current impression is that tRPC has less boilerplate code since there's no need to write both the schema and resolvers - with tRPC, you just need the resolver. I haven't really cared about this since the schema is generally pretty trivial to write out but l agree that the less you can get away with, the better. I would like to see an example of tRPC where backend (which could be multiple microservices) and frontend are in different repos but I'm guessing you would have to do `import type` and be careful you don't actually import backend code into frontend. As for the perks of GQL, I like the flexibility it gives on frontend. It's easy to write out a single query that queries multiple microservices. I would need to see how that's done with tRPC or traditional REST APIs. My impression is that frontend would need a lot of back and forth calls to get the required data when it needs to call a lot of different microservices while with GQL, Apollo Gateway does a lot of the magic for you. Some of our microservices are also Java/Kotlin so GQL definitely benefits us here.

Thank you for this really good description of what tRPC is - I saw it around Twitter, but I didn't understand why it's useful. The issue of over using GraphQL is dear to my heart - I work in a large bank, and they've recommended that all BFFs default to using GraphQL. Although everyone was enthusiastic about it because it's a chance to learn a new framework, it's resulted in over-complicated codebases for very simple BFFs, and new devs struggling to understand and extend those codebases.

What do you think about REST with openapi/swagger schema to have that contract between a backend and frontend?

It would be cool to write a plugin for Next/Nuxt/Sveltekit so you could include your backend actions in components. So you could specify backend methods the same way you currently specify frontend methods. Even cooler if it could work with FaaS and hot-deploy both ends whenever you save your component source.

This video came at a perfect time. I have been wondering about this topic for a few days now. So, in a situation where a developer is writing an entire application (frontend and backend) and has complete agency over the database, it seems like tRPC makes the most sense, right?

That is super interesting point regarding being able to update your mobile apps on the fly like that with react-native.

6:58 Thanks for the shout-out Theo! :)

I started using openapi-trpc a couple weeks ago and it is really the best of both worlds. I had some issues related to "complex" nested types, but I managed to find a way around it (so far). Also, you can later go from open-api to protobuffs and use those types in other languages. 100% recommended, Give it a try!!

We are adopting GraphQL in our company without almost no guidance or expertise, and I have to say - people just don't get it and it's getting messy really fast. And it sucks because the ideas of it is great, but for some reason people have a hard time making the correct mind shift and design the schema well

I worked for a startup that loved keeping frontend and backend teams separate, and none of the backend engineers knew how to make a good REST API, so they grabbed gRPC and proceeded to create ridiculously complex ways of saving and retrieving data. Endpoints had weird side-effects and things like pagination were treated like crazy features nobody expected. There's a reason REST was invented and took off like crazy. Web development was more like RPC before REST came along. I don't know if there's value in RPC above REST, but I'm strongly biased against it because of that experience.

Theo, great insight on trpc vs graphql

We used JRPC an my previous company. Our back, and was written Node, then got rewritten and Go. I really like the simplicity of calling a function on the server. Any thoughts on JRPC?

I'm the Flutter developer that won't let go of their ways lmao. Subscribed so I can refresh my knowledge for the React side of dev. Love your channel! I have already learned so much

Hello Theo. I love thé idea behind t3. Especially because all the stacks there are those I feel quite comfortable with. Given that NextJs is a Fullstack framework. If I want the next api be consumed by the mobile version developed in react native as well as the web. Is that pretty comfortable and easy?

I was critical on some stuff but great video and like I expected man when u get down to business - intelligent, great explanation. It’s like awww okay ya this is good stuff. Maybe I just caught some stream rants lol. Thanks 4tv !

Solid, too the point, and enjoyable :D great stuff as always

Very interesting. GQL seems to be still very popular though… Hasura with TRPC would be possible? 😉

anyone remember when rendering engines where a thing ( stuff like handlebars and thymeleaf ), React is a blessing (especially if you use TS)

did you try Odata and what do you think about it?

My users and managers care very little about backend, plus it is recurring cost and exponentially growing complexity. Stateful backends so easily become cupboards of horror! I'm going to watch, optimistic tRPC can be used ti mitigate some of those negatives.

Does TRPC even work well with Nextjs and Vercel (serverless)? I can't do a single router for all backend queries because then all my backend code will end up in a single serverless function which is horrible for performance, infact we are going through a big refactor just to avoid that

had a question: is trpc a RPC framework? I know we get fullstack typesafety but do we get protobuff levels of speed?

I heard you say, 'those few use cases where typescript is very slow for your backend'. Being a junior and self taught dev, how would one differentiate between such usecases? I generally think if I have too complex data queries/ relations or the need to call my backend too many times on most of the pages, graphql is my guy. What such thinking should I apply on when to use TS or golang for a project?

I'm kinda confused by you saying that kotlin is "dated way" and it should be replaced by typescript. Also for the backend, JVM languages are just more comfortable to work with. Dynamic one, even with type system placed ontop, would probably never be as structured and well-though unless you do it from scratch.

If trpc is just "calling a function on the backend". How is it different than just a rest api? Usually a rest endpoint is a function that does something to the backend. Or retrieves something from the backend. Isn't that just "calling a function on the backend".

I’m a Kotlin Android dev that you speak of, with React Native experience. I tend to agree with the attempt to share components between React Native and React web. My personal projects are all Typescript/React and I also use React Native, but I can’t deny the dev experience with Flutter is much better. But because Typescript allows me to hit multiple birds with one stone, I deal.

Building API version independent is amaizing. How do you do it?

I have been building a gqlgen backend with go and it’s been interesting thus far

Can you use tRPC when the front end is separate from the backend? What is the solution if the front is a react app that calls apis on a separate rails server?

Please try not to be too judgmental or arrogant about "your way". Kotlin is anything but a "dated way". And I say this as a dev who works with both (and also with GraphQL). Kotlin multiplatform can do much more and more effectively than what node/Typescript can do and I'd say that the language itself (Kotlin) is better too in many aspects. I use Typescript and node every day, and I like the tech, but calling Kotlin, Flutter or whaterver contemporary technology a "dated way" is not only plain arrogant, but it also says much about the knowledge of the person who says it.

This would be an interesting video for me since I am an average GQL enjoyer but am open to alternatives. But I immediately clicked off when your firsts words were “you need to have TS on the frontend and backend.” It’s just not feasible to tell all API consumers that they have to use TS.

How do you handle versioning with tRPC? We usually deploy the back-end and front-end at different times and prefer to have a small window of backwards compatibility between the two.

So - if i have an app where i am bound to using python on the backend for (django), how would I get something similar to tRPC? I am currently just going to use GraphQL but is there any way to get a similar setup to T3 stack with a python backend? Is my only option for something that measures up to go typescript backend?

You can use Hasura, which creates a GraphQL endpoint out of the box without any effort.

I'm confused. What does tRPC do that I don't get from a rest API and something like openapi-typescript to generate frontend types?

It kind of feels like we are going back to the past. As if we noticed how stupid we were for wanting to change things, like CSR to SSR/SSG (although we now have hydration), or from Rest and GrapQL to RPC... I wonder if we will diverge from this again in the future. This might be like retro going back on style

Many Backends use legacy code that can't really be touched. Frontend on the other hand is always looking for latest and greatest. Graphql helps me merged both in a single endpoint for apps.

THEO GO TO BED Also stuck in GQL hell at work right now Great video Much love brother

So, if trpc is a single API route, can I call it in a Flutter app (just for example), or any other non TypeScript application, and get the data? Or is it that since trpc does not return JSON, I will be unable to do this?

graphql is great for public apis, trpc no so much. trpc is great for internal apis, so is graphQL ( but requires more work ).

So tRPC is better than protobufs only if the client and server code are in the same repo, is my understanding correct? I'm sure we can use protobufs to generate client code.

It really hurts to listen to this because I'm missing out so much... At my company we're using untyped, untested and undocumented Javascript Microservices with mongodb.... Everything is a mess, we never really know what data we're gonna get... I would be so happy if I'd get any sort of typesafety at all... Even it weren't perfect..

Can you use tRPC with a graph database like neo4j

Thanks for the show

this shit goes so deep.

why not use strapi for GQL?

Great well explained !

Why do you think the GitHub GraphQL API is bad? Would love to understand the criticism and see you point out the problems you see based on the experience you have

idk but I'm using graphql and I cannot define optional parameters for a resolver's input. So in the end... Lots of useless data traveling through the network.

Is tRPC good enough for mobile apps? because one of the points graphql makes is the fetch just what you want philosophy to deal with slow, unreliable and expensive mobile data on phones.

Dated ways? I love TS but calling other ways dated is silly. Java, C#, Python are still incredible tools for building modern backends.

Can you upload your video on Spotify or Deezer ?

So its like gRPC with types?

The thing that bothers me the most with tRPC is the fact that you are selecting the query by simple string and this means no autocompletion. You can't just hit ctrl + space and see all the available queries. It can be fixed by using string-like enums but I feel that it can be solved in a better way.

What are some excellent GraphQL educational resources? Or do you expect for tRPC to really mature quickly?

i still can't get it. how can it be "the future" or "graphql killer" if it requires hard coupling frontend and backend (and omg monorepository for both), which is oblivious anti-pattern for any serious projects. Ofc it can take own place for small project, where small team is building both sides of application, but it will never kill or replace graphql or rest, until it does not have any out-of-the-box solution for projects, where frontend and backend are independent microservices

tutorial on trpc

with all the problems and anti-patterns that typescript has, using another language for backend is not a dumb idea. With highly distributed enterprise scale service ecosystems trpc won't work that well in my opinion. I personally don't enjoy coding in typescript. Golang is much more pleasant I think. Also a question, in cases where graphql is not necessary, can protobufs be used instead of trpc?

Isn't there GRPC for TS?

I'll take a statically typed Backend with a well designed REST API over pretty much anything else.

I think, tRPC is goot fit for teams that mainly consists of full stack developers. graphql is more well suited for large teams that have separate devs for frontend and backend.

i recently realized how graphql really just makes my life harder. it doubled my bugs, i have to fixed and refract code twice even with nexus. especillay when using it with prisma. i think i'm gonna trash graphql. i used to love it though for past few years but i finnally realized it's really not that usefull even with complex project.

Both tRPS and GraphQL are still very inefficient because of HTTP and JSON. If we swapped HTTP with QUIC and JSON with some custom low-level and binary parser then that would be absolutely amazing.

This man is the cat's ass of quality content. Thank you Theo. Gg

I just read a article from logrocket to understand what the actual difference to gRPC is and this is what they wrote: "While tRPC is indeed also a remote procedure call framework, its goals and basis differ fundamentally from gRPC. The main goal of tRPC is to provide a simple, type-safe way to build APIs for TypeScript and JavaScript-based projects with a minimal footprint" This has to be the stupidest reason to basically build a completely new "protocol", that is not a protocol and nobody else can use. So yeah, TS/JS people are one more time too stupid to use their own tooling and now need something like this because they can't properly deal with types, even though they already have the same data representation on the front and back-end.

This is nothing new. For example .NET's old WCF is based around this concept where you delcare an interface that serves as communcation contract. It's just creating an interface that will be implemented by your BE and then creating an object proxy on FE based on the interface. The interface's implementation becomes a controller and methods become actions with the proxy on FE serving as "smart fetch". The proxy can be generated or create at runtime using reflection. This can be generally achieved even in JS when using classes. However, this approach was eventually phased out as WCF got succeeded by ASP NET, but there are libraries that do this even for ASP NET. The tRPC seems like a downgrade as u still need to perform the tRPC call explicitly by using client.query('name', input). I think the better way to do this would be doing it as .NET did using OOP by explicitly using object (of the given interface) to perform call which would automatically map to it's implementation on the BE. You may argue that interface does not exist at runtime and thus cannot be introspected to generate routes and proxies, but you may use abstract class instead. By this FE does not have to distinguish whether the object performs HTTP calls or is just "normal" object. You may argue that there has not been anything like this in TS/JS, but I think that is generally because it died out before Node.JS was created. The benefit of joined versioning comes from the monorepor. No matter whever GraphQL, SOAP, REST etc... as long as it's a mono repo the versioning of FE and BE is joined.

I wonder what the relation of tRPC to gRPC ist, if any?

Your audio is -14.9 dB lower than it should be. I always have to turn up my speakers when listening to your videos and then have them blow my out of my chair when I start a new video by someone else :D.

what about unnecessary fields what will you get with query? GraphQL give me possibility to get only queried fields, also I can query two users by id with one query for example RPC needs not for communication only, this need to connect two parts of one application in network This is great solution for nextjs api part, but it's not GraphQL killer, because they cover different things

As a consumer I would way rather have a GraphQL endpoint. Having singular API endpoints limits you to whatever the developer had originally intended, while crafting a good GraphQL schema can enable a much broader set of use cases outside of what was originally thought of, and avoid things like over-fetching. Really click-baity title.

Im still not a tRPC user yet. But can we take type safe advantage from tRPC while our app is not monolithic? Like in real world there would be microservices, multiple frontend repo, even microfrontend, blablabla and so on. In this situation, is tRPC still a good choice?

tRPC looks cool, but it really needs a better name

Hard agree with the point about it being easy to use GraphQL to make hell. We use GraphQL a little bit at my company but we see no perceivable benefit from it and it just makes everything much more difficult.

A swift and kotlin client would be great for mobile dev.

No.

hahaha love the flutter h8

RPC => REST => GRAPHQL => REPEAT

I have used GraphQL with Contentful CMS, GraphCMS & FaunaDB. I don't know how tRPC will Integrate with these popular tools. Also Note that GraphQL Server Frameworks like GraphQL Yoga & GraphQL Helix & tools like Envelop, Envelop Plugins & GraphQL Tools with GraphQL Mesh & GraphQL CodeGen & more... are making GraphQL DX Awesome. Please make more explorations to current situation before going online.

You should rather compare tRPC with gRPC and then ask "Why tRPC?"

I dont know anything except graphql Been using it since day one of employment 🥴

TL;DR - If you're not using TypeScript in front and back-end, and don't have full code visibility, This Tool Is Not For You. Move along, Move along.

Cool

t3 uses Prisma... It's quite easy to go to GQL from there. Why bother with your tRPC?!

Hey please don't swear

Graphql dead because you can get typescript coupling between frontend and backend? Yolo

"is GraphQL DEAD?? so..this requires type script on both the back end and the front end" lol good jokes

If you use Postgraphile, you dont need to write resolvers.

Based

Your content is great but I need to speed up the video to 1.5 cause you speak so slow 😂 😂

I am using python as my backend very often and dont see why this should be dated or smth. If u r more comfortable with one or the other go and use it

GraphQL -> perfect for a team of FE React devs and BE Rails devs. tRPC -> perfect for fullstack Typescript devs.

Why you guys cussin educational videos? Its so unsafe to watch even educational next to our kids? This just push me to unsubscribe

tRPC will have a short lifetime. In real large companies, no one will commit themselves to a single technology. This has to do with the availability of developers, and above all that this technology is not the optimal solution in all areas. The RPC stack isn't new, and there's a reason it hasn't caught on.