kamilafsar
Joined 14 years ago
Joined 14 years ago
But you asked what would you expect. At least don’t block me to update. Tell me it’s not officially supported. But let me install whatever OS I want, at my own risk.
The problem is not even the OS. It’s the whole ecosystem of apps that require a certain OS version.
I’m stuck on 10.13 with my iMac from 2012. The hardware serves me well, it does exactly what I need it to do. I’m just stuck on an old OS.
I’m gonna try OpenCore legacy patcher for sure.
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!
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 :)
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.
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
https://www.typescriptlang.org/docs/handbook/2/template-lite...
Unless you’re implementing a standard, software engineering is 50% communication with peers/clients/users, if not more..
For instance, I know Turkish is very consistent: it was refactored in 1928 with the birth of Turkey. Turkish is quite high in the rankings. I don't think because there's loads of data available, but because of its consistency. Contrary, English has loads of data, which should compensate for it inconsistency.
So you could use it on a chromebook as well.
I like the idea, and as PG often says the best ideas often sound crazy at first.
Glad someone other than me is trying I guess :-)
It has a minimal API, literally one function, with which you can expose your server’s functions. It will generate a Typesafe SDK for your frontend(s), packed with all models you’re using. It will also generate a server which will automatically validate input & output to your server.
One thing I’ve seen no other similar solution do is the way we do error handling: throw an error on the server and catch it on the client as if it was a local error.
As I said, it’s only meant for teams who have full stack TypeScript. For teams with polyglot stacks an intermediate like protobuf or GraphQL might make more sense. We generate a TS declaration file instead.