tRPC: the API Game-Changer?

[@_sjoe]

I’m really excited to see the upcoming project! There’s so much value in getting a glimpse into the way other devs do things There’s always something new to pick up on.

[@KodapsAcademy]

The first video is up :)

[@ausar2379]

Good info dude. Learning so much. Thanks!

[@Kats0unam1]

You still think tRPC is a good choice for a backend specially considering an easy scalable language like Go ?

[@KodapsAcademy]

I think what I already said: that for a backend in TypeScript, tRPC can be a natural fit. tRPC doesn't compare to Go, it's a library on top of a TypeScript backend. In those circumstances it makes sense because it provides a native way to share type information between TypeScript server and the client-sides (which Go would not be able to do natively since it does share the same language). So it is a horses for courses question.

[@bonsayeb9620]

Do you mind giving an example to why tRPC is unsuitable for public facing API's and a solution if you find yourself in that situation. Thank you in advance.

[@KodapsAcademy]

It’s unsuited to create public facing APIs because public APIs are intended to be agnostic to the client’s technology, i.e. work under JS, Python, cURL, PHP etc. So tRPC can’t be used to create public APIs nor consume them, since it is only for TypeScript.

[@27sosite73]

ty mate n1

[@millennia]

How would this work in offline?

[@KodapsAcademy]

I’m not sure I understand your question : tRPC is intended for client / server communication so isn’t suited to offline use :)

[@millennia]

​@@KodapsAcademy Thank you

[@hakuna_matata_hakuna]

The comparisons to GraphQL are very unfair, gql exposes graph of data and not just data from a specific endpoint