alexdotjs
Joined 6 years ago
Karma
35
Submissions
10
Member since
Apr 16
Recent submissions
Comment · 3 years ago
We a tool bring which lets you track schema changes it over time and also ability to have an approval workflow for schema changes.
Would that help your team?
Happy to give you a demo if you reach out on Twitter dms or email ([email protected])
Comment · 3 years ago
Heya! Creator of tRPC here, just wanted to drop by and say thanks for all the love ♥
Comment · 3 years ago
Here's an example of testing: https://github.com/trpc/examples-next-prisma-starter/blob/ma...
Comment · 3 years ago
Thanks for the input! We have thought about it a lot.
The biggest challenge with trpc right now is that the API is transient so it's not obvious when you might be braking clients in flight and that you often can't guarantee perfect sync of deployments as you're rightly pointing out.
Once we have some more tooling around it, you'll be able to get the benefits of a traditional API where you consciously choose when to break the spec, but with the productivity benefits of not having to manually define it. I think that will scale pretty well.
Comment · 3 years 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)
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.
Comment · 4 years ago
It won't scale forever. You'll need project references in the same way as we need in tRPC on large projects.
Comment · 4 years ago
Heya! Creator of tRPC here. Seen some comments on trpc's ts perf issues.
Some notes:
- The problems with tRPC "at scale" are fixable by using project references, but not going to downplay that it's an annoying refactor to do (https://github.com/microsoft/TypeScript-Handbook/blob/master...)
- All of the problems with trpc are inherent of any ts thing that is heavilily reliant on inference (hence also blitz) (https://github.com/microsoft/TypeScript/wiki/Performance#wri...)
- The ts perf things that set trpc apart and make you feel it earlier in tRPC than blitz are largely resolved by the new major of trpc that is currently in a stable alpha (stable in terms of no known bugs, but API might change)
Comment · 4 years ago
Yup, with the optional `output`-property we actually have all the type information needed to generate an openapi-schema.
See this for more info: https://github.com/trpc/trpc/issues/1724
Comment · 4 years ago
Awesome to see my lil' baby on the frontpage!
twitter.com/alexdotjs