4 ms·
If you've got Typescript on front-end and back-end then I'd recommend looking at tRPC. The schema is your types, which might often just be the type of your DB r
by vosper 4y ago
If you've got Typescript on front-end and back-end then I'd recommend looking at tRPC. The schema is your types, which might often just be the type of your DB response, leading to low-code but fully type-safe coding.
https://trpc.io/ https://trpc.io/
- sgammon 4y agopretty useless as an RPC layer if it imposes language restrictions…
- bluepizza 4y agoWhy?
- sgammon 4y agoBecause the point of an RPC layer is to communicate between pieces of software, and you often have no guarantee of control over the languages they are written in.
- bluepizza 4y agoThat’s true for microservices environments in modern companies. But a lot of traditional companies have languages and versions locked and mandated. The point of RPC layer is just to remotely call a procedure.
- akshayshah 4y agotRPC is awesome - if you're writing full-stack TypeScript and don't care about other languages, it's very convenient. Protobuf might be a more appealing choice if you want to support clients in other languages, or if you're interested in getting a bit more value out of your contract language (e.g., breaking change detection).
- junon 4y agoOr just use AJV which has the ability to statically represent JSON Schemas as full-fledged types, so that the schemas themselves become the authoritative IDL, via the new JSONDataType in AJV@7.
- vosper 4y agotRPC is more than schemas, though - in tRPC schemas are actually supplied by Zod. tRPC is more of a framework that abstracts away building an API and makes removes the perception of a serialization barrier between client and server. It feels like it's all one codebase. It also carries types across, so that changing (eg) the shape of a database response will immediately throw up type errors in client-side code.