[kamilafsar]

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

Comparison: https://phero.dev/docs/comparisons/tRPC

[ctvo]

> 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.

[kamilafsar]

Good point!

We use Phero extensively in mobile apps projects, so we know the pain of maintaining API versions and backward compatibility hell.

Phero generates a declaration file with all functions you expose, and bundles dependent domain models (interfaces, type aliases, enums, etc) with it. Currently there's only one version. Our plan is to let users pin versions of this declaration file (we call it the manifest file).

Then we build cli commands to compare them and actually tell if they are compatible. This way you know if it's safe to deploy a new version of your API without breaking existing clients. These are all future plans of course, but in the scope of the project.

[Wissmueller]

> 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”

[ushakov]

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]

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 :)

[jitl]

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