Background
Last week I joined an event about GraphQL VS TRPC discussion hosted by Guild in London. The creator of tPRC Alex and urql Gr...
For further actions, you may consider blocking this person and/or reporting abuse
I believe that gRPC has an advantage over tRPC because it is multilingual. But I don't rule out that tRPC could grow someday to new horizons. We can only wait.
Сongratulations 🥳! Your article hit the top posts for the week - dev.to/fruntend/top-10-posts-for-f...
Keep it up 👍
Thanks! I will do my best.
How will tRPC work with other languages like python, Go, Rust etc. ?
For now, it's Typescript only because it's the only lanaguage that could be used for both frontend and backend.
This is simply not true. Sure if you're building a single web app in start up mode this is an attractive solution to get you going. It's also totally possible to build a backend and front end in kotlin, swift, c++ or many other languages. One great thing about rest APIs and graphql is that they allow you to develop your server logic once and use it in all your website's, mobile apps, desktop apps and iot devices. I'd like to see how this scales to a business that has been alive more than 5 minutes.
Maybe I didn’t state it clearly. What I was trying to say is that the way tRPC works requires both frontend and backend using the same language, so it’s Typescript only.
I think you are right, scale is indeed an issue usually brought up, as I also mentioned in the post. But there does have some online businesses has used tRPC, like:
cal.com
You can see more here:
Drop your company name, svg logo, link to your website, and links to any repos using tRPC!🙌
Some companies / sites I know myself
Anyway, as I said in the post tRPC is just two years old, it’s the future that matters.😄
There is a trpc-openapi help you make it REST, have a look at: github.com/jlalmes/trpc-openapi
To say that an API is a "way for two or more computer programs to communicate with each other" is equivalent to saying that API is a computer network. For computer network is also a way for "two or more computer programs to communicate with each other". Or saying that everything is a part of the universe. Of course it is.
So what is API?
I would focus on the letter "I" in "API, i.e. it is an interface.
What kind of interface?
Letters A and P tells us that it is Application Programming Interface. Now, for the last few decades, application programming was about two things: components and services. CBD (Component Based Development) pretty much explained everything about components, so let's focus on services.
What is a service?
Service is a remotely accessible component.
There are 3 things that characterize every service:
Remember that we defined service as a remotely accessible component. In other words, service interface and service implementation help with this remote access part (as not every component is remotely accessible, of course).
But what does service interface actually mean?
Service interface represents a contractual agreement between parties, just like contracts in legal documents where obligations of the service provider (an entity that offers a particular service) are stipulated in the contract precisely.
In the last decade or so, we moved from SOA paradigm to microservices. Hence, when we say "service interface" we 99% of time mean "microservice interface". That is what API is, a design contract for accessing a microservice component remotely.
Of course, we can also say that APIs are an integration style, because it markedly differs from other integration styles such as file transfer, MOM, distributed objects, and shared databases.
Re: "there is no need for discoverability as you can directly go to the definition in the code."
I don't follow this logic. If you own the backend of any system, built with any technology, the notion of "discovery" is eliminated, right? That's a tautology: You don't need to discover what you control.
And for all technologies, if you don't own the back end, you need to "discover" it in some sense (automatically thru GraphQL schemas, or SOAP WSDLs -- or manually, by reading REST API documentation).
So does tPRC offer any discoverability advantages?
you are right, the "discovery" is actually eliminated. Sorry for the confusion caused.
"If you own the backend of any system, built with any technology, the notion of "discovery" is eliminated, right?"
This statement could only hold true for some "personal projects", where past, present and future developers is all one and the same person. In practice, with old devs leaving and new joining the discovery is a constant process, so the culture of good practices, including extensive documentation are necessary. Furthermore, for the statement “Always code as if the guy who ends up maintaining your code will be a violent psychopath who knows where you live.”, what usually holds true is that maintainer is yourself, just 6+ months down the track, when you forgot all the details, and need remainders.
Through it, I relived my own journey from SOAP to REST to GraphQL. I am still not on the bandwagon of gRPC/tRPC yet. But, I believe that it’s the next step in the evolution of these protocols. Thank you for writing this article.
tRPC looks good to me but (there is always a but) it actually doesn't looks like a good answer to me. First of all, it's only TypeScript for now witch is a really bad idea right now. Don't take me bad. There are a lot apps whos backend are in other languages. Actually, there are many apps that use several backend languages.
Looks really good to make hhtp calls as a function call but that's essentially RPC and, by my experience, this can lead to several problems.
The best approach for me, after all, is REST and, of course, GraphQL.
With the first one, the backend team just have to tell you what the backend will respond. The problem is that you may get more data than you want. And this is a security issue.
In the other hand, GraphQL just gives you the data you want, and it's ok, but backend may be overkill as backend is getting more data than you want. But al least you just get eat you want.
For me, the best approach is to be in a good communication with the backend team to get the right data from the backend as it passes a DTO or a really good shaped GraphQL query. But this one can be tricked down too.
TL;DR;
There is no magical anwer right now. But REST with an awesome documentation seems to be the best answer.
There is no free lunch, so it’s all about trade-offs. In general, the less the framework does, the more flexibility you have, but the more work you need to do by yourself. I think GraphQL and REST would still be the most popular ones for a while, but I always love to see the new challenger come to play which could push the development world to a better place.
I agree that REST has the most flexibility but it also means that there are lots of choices you need to make on your own like choosing the right tool to generate the documentation. 😄