tRPC – Build and consume typesafe APIs without schemas or code generation
1–10 of 223 posts
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#2I've used tRPC and Next.js for a couple of personal projects and it's been a great experience. Hard to beat on iteration speed, especially when used with a pre-configured template like Create T3 App: https://create.t3.gg/.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#3I've used tRPC and Next.js for a couple of personal projects and it's been a great experience. Hard to beat on iteration speed, especially when used with a pre-configured template like Create T3 App: https://create.t3.gg/ .
Does it now work properly with Next 13 and server components?
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#4I am up voting this because its a good idea and you have really nice web site.
I wrapped up something like this myself a few weeks ago, so I am in a position to offer some suggestions other people may not think about.
The most common mistake I see with RPC, especially WebSockets, using Node.js is that they must be based off of HTTP. My attempt is based upon WebSockets, RFC 6455, where RPC is a generic term for socket based communication streams not specified against any single frame definition scheme. Since these technologies are raw sockets that include their own conventions for handshakes, optional frame header definitions, and possible security conventions there is no need for HTTP. In the OSI model HTTP is layer 7 where TCP sockets are layer 4. In Node that means just using the net/tls libraries opposed to the http based descendant libraries. Since, in Node, the http library descends from from the net library and https descends from tls which descends from net http always imposes overhead that TCP based sockets do not require.
There are three benefits for executing a socket server over HTTP:
1) You are only using port 443
2) Simple and familiar implementation from Node
3) HTTP 1.1 is session-less, which allows anonymous untrusted connections. That is how the web works, but its less ideal for a security focused implementation.
The reasons to not do this include CPU cost. Running sockets over HTTP increases processing overhead which reduces the number of concurrent streams you can offer and substantially slows down processing of incoming frames. In order to reduce your execution to a single port without sacrificing performance you could run HTTP over your socket implementation which allows you to customize your approach to security, but that would also require writing your own HTTP libraries.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#5I am up voting this because its a good idea and you have really nice web site. I wrapped up something like this myself a few weeks ago, so I am in a position to offer some suggestions other people may not think about. The most common mistake I see with RPC, especially WebSockets, using Node.js is that they must be based off of HTTP. My attempt is based upon WebSockets, RFC 6455, where RPC is a generic term for socket…
My issue with websockets is, they are still being blocked in corporate proxies. I particualarly see this in banks or research-places, where sockets are blocked to prevent data leaking out of the network.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#6end-to-end (as long as the backend is Node.js)
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#7We’ve use an API style similar to tRPC at Notion, although our API predated tRPC by 4 years or so.
You can build this kind of thing yourself easily using Typescript’s mapped types, by building an object type where the keys are your API names, and the values are { request, response } types. Structure your “server” bits to define each API handler as a function taking APIs[“addUser”][“request”] and returning Promise. Then build a client that exposes each API as an async function with those same args and return type.
We use this strategy for our HTTPS internal API (transport over POST w/ JSON bodies), real-time APIs (transport over Websockets), ElectronWebview APIs (transport over electron IPC), and Native (iOS, Android)Webview APIs (transport over OS webview ipc).
For native APIs, the “server” side of things is Swift or Kotlin, and in those cases we rewrite the request and response types from Typescript by hand. I’m sure at some point we’ll switch to a binary based format with its own IDL, but for a single cross-language API that grows slowly the developer experience overhead of Protobuf or similar hasn’t seemed worth it.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#8Can highly recommend over plain REST as an alternative to graphql. The iteration speed with instant feedback is incredible. Perfect pair with NextJS.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#9I have used tRPC for two ~50k loc web applications and love it. The DX is incredible. But I feel like tRPC had its hype time some time ago, so RSC’s hype quickly caught up. These days everyone speaks about whether to use or not to use RSC while there is such a great stable solution like tRPC out there. I am not against RSC, but there is way too much discussion about it. tRPC is a super pragmatic way to create applications with these days!
Edit: RSC = React Server Components - which come with their own read/write data philosophy.
Re: tRPC – Build and consume typesafe APIs without schemas or code generation
#10I am up voting this because its a good idea and you have really nice web site. I wrapped up something like this myself a few weeks ago, so I am in a position to offer some suggestions other people may not think about. The most common mistake I see with RPC, especially WebSockets, using Node.js is that they must be based off of HTTP. My attempt is based upon WebSockets, RFC 6455, where RPC is a generic term for socket…
My issue with websockets is, they are still being blocked in corporate proxies. I particualarly see this in banks or research-places, where sockets are blocked to prevent data leaking out of the network.
I used to work at a giant bank.
The reason they might be blocked by big banks is due to deep packet inspection. How that works is that the bank intercepts certificates on TLS socket establishment for normal web traffic so that the bank proxy becomes a formal "main in the middle". They do this to provide deep packet inspection on all encrypted traffic that goes out and comes in. That level of packet inspection is more challenging with something like RPC/WebSockets because its a binary stream, where HTTP just uses plain text for its header data.
I can remember using Reddit, when I still used Reddit, when starting at the bank and I remember Reddit making heavy use of WebSockets that worked just fine from within the bank even though I was behind the bank's proxy. This was more than 6 years ago, but I believe the WebSocket traffic at that mega bank was just relayed through proxy just like the HTTP traffic and I also want to say Reddit served the WebSocket traffic different from the HTTP traffic, but I cannot remember for sure.