4 ms·
The downside of an approach like this is that it limits you to a single programming language on both the frontend and backend. This is exactly the reason RPC fr
by EdSchouten 3y ago
The downside of an approach like this is that it limits you to a single programming language on both the frontend and backend. This is exactly the reason RPC frameworks like gRPC use an IDL.
- catern 3y agoWell, that's not fundamental. There are plenty of projects that support generating typed bindings for libraries in one language for use by programs in another language. You could do the same thing here.
- xyzzy_plugh 3y agoFundamentally you go against the grain by generating an IDL from source code. I've never seen this done properly such that it is an improvement over just authoring the IDL in the first place and generating from that. If your IDL isn't a first-class citizen then what do you expect the derivatives to be?
- lunarcave 3y agoI agree, and disagree. I agree that it limits the usage of the tool in a polygot environment. I disagree it's a downside. The absence of an intermediary language does give some benefits to the first class citizen (in this case, Typescript). However, there are some other developments [1] which attempt to make the Typescript type system an IDL to allow for better interop. [1] https://github.com/Aleph-Alpha/ts-rs https://github.com/Aleph-Alpha/ts-rs