4 ms·

Shameless plug: I’m one of the authors of Phero [1]. It’s goal is similar to tRPC: fullstack typesafety between your server and client(s). One difference is sy

Shameless plug: I’m one of the authors of Phero [1]. It’s goal is similar to tRPC: fullstack typesafety between your server and client(s). One difference is syntax: Phero leverages the TS compiler api to generate parsers for your backend functions. It will parse input and output of your api functions, automatically, based on the types you define for your functions. It will generate a declaration file of your api and generate an RPC style client SDK for your frontend. Another difference is that it aims to be more batteries includes. [1] https://github.com/phero-hq/phero https://github.com/phero-hq/phero Comparison: https://phero.dev/docs/comparisons/tRPC https://phero.dev/docs/comparisons/tRPC

ushakov 4y ago
As far as I understand Phero needs a build-step, where as tRPC does not This means you won't be getting the same real-time experience/feedback you get with tRPC, because you will still be waiting for Phero's compiler to complete the build I was expecting something like that to emerge and initially wanted to go into that direction with Garph (see my comment below) but we ultimately decided that a code-gen does not give you the same amazing feeling so we ended building a pure TypeScript library Good luck with Phero in any case!
- kamilafsar 4y ago
  Yes, Phero has a build step. Phero does come with a CLI and will watch code changes, build your TS alongside with an client SDK. In our experience the latency between changing something in your API, and seeing compile errors arise in the client is just a few seconds. And this only matters when your API contract changes, which is of course not always. Not a biggy in our eyes. In order to run, you'd need to compile TS anyways. :) In our opinion this is well worth the "magic" Phero adds: it will work with plain TS. No "t.string" like apis to build your apis/models. Matter of taste I guess :)
  - arnorhs 4y ago
    Not to take away from your explanation, but this is actually the key point that a lot of developers have been fighting in the last couple of years. We've "had" end-to-end typesafety with codegen tools openapi/swagger and graphql etc. However, the big issue with a lot of those tools is that you end up having to manage this compile step. The real magic of trpc is exactly this point about it being without a compiler, where the types are derived from the very same typescript files - this is what gives it this immediacy and feeling of it being instant and not having to deal with a compile step. I've always wondered whether we'd get the same benefits and niceties with a really streamlined compiling approach - perhaps something like phero. But it's just a little harder of a sell compared to the built-in typesafety you get from trpc
    - kamilafsar 4y ago
      There is a difference with approaches like openapi/swagger/graphql though. With Phero you define your models with plain TS. Our code-gen will "just" copy the exact same models to your client SDK. The DX is night and day. We believe domain models are the most important part of your codebase. We don't like to define them in an intermediate language like graphql/swagger/graphql/you-name-it. Because we support plain TS as "input" if you will, you can use all features and greatness TS comes with. Like generics, conditional types, mapped types, even template literal types!
      - arnorhs 4y ago
        fair enough, i can imagine that feeling pretty nice.
ctvo 4y ago
> Stop assuming data is of the type you’re expecting. You know it is, period. > Know when you break compatability with the frontend, before even running it: TypeScript has your back. Do you? Your front-end and back-end, regardless if they use the same source for their interface contract, aren't deployed as a unit. At least not always, and not in the single page application use cases you're targeting. How do you handle versioning and protocol compatibility? Across all these frameworks, it feels like a footgun your users will discover on their own.
- Wissmueller 4y ago
  > Across all these frameworks, it feels like a footgun your users will discover on their own Exactly. tRPC and other projects alike don’t provide you an actual API that you can later consume, but an RPC “glue”
  - alexdotjs 4y ago
    We have an RPC spec in tRPC :) One big difference in philosophy here is that tRPC is not designed to be used for cases where you have third party consumers. It's built for situations where you control both ends. (That said, you can use trpc-openapi for the endpoints that are public) On versioning: it's 2023 & in most cases, you can solve versioning in other ways than maintaining old API versions indefinitely. For RN there's OTA, for web you just need to reload the page or "downgrade" your SPA-links to a classic link to get a new bundle (did an example here https://twitter.com/alexdotjs/status/1627739926782480409 https://twitter.com/alexdotjs/status/1627739926782480409) Also, we'll release tooling to help keeping track of changes in cases where you can't update the clients as easily. GraphQL is amazing but it isn't a silver bullet either, it has its own complexity that you have to accept as well.
    - vosper 4y ago
      > One big difference in philosophy here is that tRPC is not designed to be used for cases where you have third party consumers. It's built for situations where you control both ends. (That said, you can use trpc-openapi for the endpoints that are public) I'm a happy tRPC user, and this is my use case. Our web application has no client other than our web frontend. I can't see a situation when it would (and I would bet this is true for most web applications), so I am very happy with how tRPC has worked out. I did recently create a more limited data API, and for that I used express-zod-api [0] which I like very much.
deleted 4y ago
[deleted]
jitl 4y ago
I like this approach of using the Typescript compiler API to produce the runtime type validator from the TS type, instead of the other way around! I started working on a toolkit to compile Typescript types to arbitrary downstream languages like Protobuf and Python/MyPy, but the last 20% of polish eludes me. My work is here: https://www.npmjs.com/package/@jitl/ts-simple-type https://www.npmjs.com/package/@jitl/ts-simple-type

ushakov 4y ago

As far as I understand Phero needs a build-step, where as tRPC does not This means you won't be getting the same real-time experience/feedback you get with tRPC, because you will still be waiting for Phero's compiler to complete the build I was expecting something like that to emerge and initially wanted to go into that direction with Garph (see my comment below) but we ultimately decided that a code-gen does not give you the same amazing feeling so we ended building a pure TypeScript library Good luck with Phero in any case!

kamilafsar 4y ago
Yes, Phero has a build step. Phero does come with a CLI and will watch code changes, build your TS alongside with an client SDK. In our experience the latency between changing something in your API, and seeing compile errors arise in the client is just a few seconds. And this only matters when your API contract changes, which is of course not always. Not a biggy in our eyes. In order to run, you'd need to compile TS anyways. :) In our opinion this is well worth the "magic" Phero adds: it will work with plain TS. No "t.string" like apis to build your apis/models. Matter of taste I guess :)
- arnorhs 4y ago
  Not to take away from your explanation, but this is actually the key point that a lot of developers have been fighting in the last couple of years. We've "had" end-to-end typesafety with codegen tools openapi/swagger and graphql etc. However, the big issue with a lot of those tools is that you end up having to manage this compile step. The real magic of trpc is exactly this point about it being without a compiler, where the types are derived from the very same typescript files - this is what gives it this immediacy and feeling of it being instant and not having to deal with a compile step. I've always wondered whether we'd get the same benefits and niceties with a really streamlined compiling approach - perhaps something like phero. But it's just a little harder of a sell compared to the built-in typesafety you get from trpc
  - kamilafsar 4y ago
    There is a difference with approaches like openapi/swagger/graphql though. With Phero you define your models with plain TS. Our code-gen will "just" copy the exact same models to your client SDK. The DX is night and day. We believe domain models are the most important part of your codebase. We don't like to define them in an intermediate language like graphql/swagger/graphql/you-name-it. Because we support plain TS as "input" if you will, you can use all features and greatness TS comes with. Like generics, conditional types, mapped types, even template literal types!
    - arnorhs 4y ago
      fair enough, i can imagine that feeling pretty nice.

ctvo 4y ago

> Stop assuming data is of the type you’re expecting. You know it is, period. > Know when you break compatability with the frontend, before even running it: TypeScript has your back. Do you? Your front-end and back-end, regardless if they use the same source for their interface contract, aren't deployed as a unit. At least not always, and not in the single page application use cases you're targeting. How do you handle versioning and protocol compatibility? Across all these frameworks, it feels like a footgun your users will discover on their own.

Wissmueller 4y ago
> Across all these frameworks, it feels like a footgun your users will discover on their own Exactly. tRPC and other projects alike don’t provide you an actual API that you can later consume, but an RPC “glue”
- alexdotjs 4y ago
  We have an RPC spec in tRPC :) One big difference in philosophy here is that tRPC is not designed to be used for cases where you have third party consumers. It's built for situations where you control both ends. (That said, you can use trpc-openapi for the endpoints that are public) On versioning: it's 2023 & in most cases, you can solve versioning in other ways than maintaining old API versions indefinitely. For RN there's OTA, for web you just need to reload the page or "downgrade" your SPA-links to a classic link to get a new bundle (did an example here https://twitter.com/alexdotjs/status/1627739926782480409 https://twitter.com/alexdotjs/status/1627739926782480409) Also, we'll release tooling to help keeping track of changes in cases where you can't update the clients as easily. GraphQL is amazing but it isn't a silver bullet either, it has its own complexity that you have to accept as well.
  - vosper 4y ago
    > One big difference in philosophy here is that tRPC is not designed to be used for cases where you have third party consumers. It's built for situations where you control both ends. (That said, you can use trpc-openapi for the endpoints that are public) I'm a happy tRPC user, and this is my use case. Our web application has no client other than our web frontend. I can't see a situation when it would (and I would bet this is true for most web applications), so I am very happy with how tRPC has worked out. I did recently create a more limited data API, and for that I used express-zod-api [0] which I like very much.

deleted 4y ago

[deleted]

jitl 4y ago

I like this approach of using the Typescript compiler API to produce the runtime type validator from the TS type, instead of the other way around! I started working on a toolkit to compile Typescript types to arbitrary downstream languages like Protobuf and Python/MyPy, but the last 20% of polish eludes me. My work is here: https://www.npmjs.com/package/@jitl/ts-simple-type https://www.npmjs.com/package/@jitl/ts-simple-type