6 ms·

I find it really sad that these efforts always stop at working in language X, but no formal specification exists that would make it possible to create an intero

by janosd 3y ago

I find it really sad that these efforts always stop at working in language X, but no formal specification exists that would make it possible to create an interoperable version in a different language. I love TypeScript, but for various reasons one may need a different backend language on the server side. Yes, OpenAPI is a thing, but I have yet to see an OpenAPI spec + code generator that works out of the box and doesn't need a whole lot of fiddling and workarounds. I also understand that it's hard to create something truly interoperable, my previous job was building a usecase-specific typing system, but adding yet more single-language ?RPC implementations isn't really helping. Obligatory XKCD reference: https://xkcd.com/927/ https://xkcd.com/927/

marksomnian 3y ago
I think part of why tRPC shines is because it's tightly coupled to TypeScript (and especially Zod, its schema validation library of choice - many of its features map 1:1 onto TypeScript concepts that don't exist in many other languages), which means it can avoid many of the issues that OpenAPI generators have. I'd also like to see a good TS-first OpenAPI client - Fern [0] is probably the closest I've seen. In general in my experience, when you take away the constraint of inter-language interop, you get much smoother DX because you can take advantage of language features. A good example would be the lack of native date/time types in JSON - valuable for interop because different languages handle dates differently, but painful when you're going to/from the same language. Web applications are a special case, because the client-side is effectively constrained to either JavaScript or WebAssembly (except you'd still need at least some JS in the latter case), so it follows that you'll get the best DX if you have JS or TS on both sides of the stack, especially if you can set up your project in a way that lets you share code between both. Not always an option, but I've always felt more productive (as a full-stack dev) when I've been using TS on both the client and server, compared to TS on the client and another language on the backend. [0]: http://buildwithfern.com/ http://buildwithfern.com/
- dsinghvi 3y ago
  :wave: Hey Mark -- I'm one of the primary contributors to Fern. +1 to your comment about how needing to support multiple languages results in not being able to leverage certain language specific features. We've tried the best to manage the trade-offs here, but there's a limit to what you can do. If you have feedback on how we can improve the TypeScript client, feel free to comment here or create an issue on our repo (https://github.com/fern-api/fern https://github.com/fern-api/fern)!
clintonb 3y ago
I prefer building an OpenAPI-compatible API over tRPC to avoid being stuck on Typescript. I don’t fault the creators of tRPC for their decisions. It’s their project, and they don’t have to build interoperability. You can always use gRPC for that. I would prefer they focus on doing their one thing well than trying to please everyone only to end up pleasing no one.

by janosd 3y ago

marksomnian 3y ago

I think part of why tRPC shines is because it's tightly coupled to TypeScript (and especially Zod, its schema validation library of choice - many of its features map 1:1 onto TypeScript concepts that don't exist in many other languages), which means it can avoid many of the issues that OpenAPI generators have. I'd also like to see a good TS-first OpenAPI client - Fern [0] is probably the closest I've seen. In general in my experience, when you take away the constraint of inter-language interop, you get much smoother DX because you can take advantage of language features. A good example would be the lack of native date/time types in JSON - valuable for interop because different languages handle dates differently, but painful when you're going to/from the same language. Web applications are a special case, because the client-side is effectively constrained to either JavaScript or WebAssembly (except you'd still need at least some JS in the latter case), so it follows that you'll get the best DX if you have JS or TS on both sides of the stack, especially if you can set up your project in a way that lets you share code between both. Not always an option, but I've always felt more productive (as a full-stack dev) when I've been using TS on both the client and server, compared to TS on the client and another language on the backend. [0]: http://buildwithfern.com/ http://buildwithfern.com/

dsinghvi 3y ago
:wave: Hey Mark -- I'm one of the primary contributors to Fern. +1 to your comment about how needing to support multiple languages results in not being able to leverage certain language specific features. We've tried the best to manage the trade-offs here, but there's a limit to what you can do. If you have feedback on how we can improve the TypeScript client, feel free to comment here or create an issue on our repo (https://github.com/fern-api/fern https://github.com/fern-api/fern)!

clintonb 3y ago

I prefer building an OpenAPI-compatible API over tRPC to avoid being stuck on Typescript. I don’t fault the creators of tRPC for their decisions. It’s their project, and they don’t have to build interoperability. You can always use gRPC for that. I would prefer they focus on doing their one thing well than trying to please everyone only to end up pleasing no one.