3 ms·
The badness tends to not start in your example - which is the most trivial example of an RPC - but when you don't know / care if a function is really a stub for
by bigDinosaur 4y ago
The badness tends to not start in your example - which is the most trivial example of an RPC - but when you don't know / care if a function is really a stub for some kind of remote invocation. Before you know it you're knee deep in a sea of distributed systems problems where instead of a clean separation between client and server, half your client is on the local machine, the other half is on a remote machine, and the state is also weirdly split. Of course, you can replicate the same mistakes with a REST API, but at least that's by definition more explicit about state transfer etc.
- andkenneth 4y agoThe thinking around a similar (but more mature) project, tRPC is interesting around this. They're very clear about the fact that it's designed for tightly coupled typescript web app monorepos. I believe the creator even was talking about the name not being ideal, but it might be too late to change. Aside from maybe being able to generate an OpenAPI spec (something that the tRPC community is working on), it's just going to fall apart outside of web apps. But for those developers it's great for eliminating this weird step where we need to think about all our data going into a completely unstructured string (json) when going between our server and client. For most full stack JS/TS apps that's all you need.
- joshxyz 4y agoAny examples of that half state in client and other half in server? Reeally clueless about this stuff as a newbie dev, first time hearing that