3 ms·

I've personally been using ts-rest for my projects, which is traditional REST but allows one to autogenerate types and API docs from a zod schema. tRPC seems c

I've personally been using ts-rest for my projects, which is traditional REST but allows one to autogenerate types and API docs from a zod schema. tRPC seems cool, but seems riskier to go with an alternative to REST or GraphQL, especially if you intend to make your API public and/or have multiple consumers of your API.

zukzuk 3y ago
tRPC is not at all intended to ever be a public API, the way REST or GraphQL is. It's meant to be a tight, private connection between your client and your server. If you use tRPC in your stack but want a public API, you will almost certainly need to build that out separately, via traditional REST, or GraphQL, or maybe gRPC. This feels all kinds of wrong initially, and there are some obvious and not so obvious disadvantages to this, but honestly it's not all bad when you get down to it.
- tough 3y ago
  At an open source company I worked briefly, we used tRPC, and I was tasked with making the Enterprise API, We went with a nextjs app, abstracted away our tRPC routers into a package and our monorepo, and used tRPC different routers both from our webapp and the API apps. This works great! You end up not repeating your logic all over the place, and make thin wrappers on your nextjs api endpoints or whatever to handle the differences between implementations
t1mmen 3y ago
I’m also singing ts-rest.com’s praise these days. Admittedly a small project with <25 endpoints atm, but holy crap, I am saving SO MUCH TIME on implementations, documentation, and bug hunting. I have separate packages (in a monorepo) for the “contract definition” and the “API implementation” (which is currently NextJS, but likely Express in the future — and the migration path looks like very smooth sailing) Request/response validation, OpenAPI spec, fetch & react-query clients without any additional effort. Mocks for tests auto-generate based on contract definition as MSW. It almost feels too good to be true.

zukzuk 3y ago

tRPC is not at all intended to ever be a public API, the way REST or GraphQL is. It's meant to be a tight, private connection between your client and your server. If you use tRPC in your stack but want a public API, you will almost certainly need to build that out separately, via traditional REST, or GraphQL, or maybe gRPC. This feels all kinds of wrong initially, and there are some obvious and not so obvious disadvantages to this, but honestly it's not all bad when you get down to it.

tough 3y ago
At an open source company I worked briefly, we used tRPC, and I was tasked with making the Enterprise API, We went with a nextjs app, abstracted away our tRPC routers into a package and our monorepo, and used tRPC different routers both from our webapp and the API apps. This works great! You end up not repeating your logic all over the place, and make thin wrappers on your nextjs api endpoints or whatever to handle the differences between implementations

t1mmen 3y ago

I’m also singing ts-rest.com’s praise these days. Admittedly a small project with <25 endpoints atm, but holy crap, I am saving SO MUCH TIME on implementations, documentation, and bug hunting. I have separate packages (in a monorepo) for the “contract definition” and the “API implementation” (which is currently NextJS, but likely Express in the future — and the migration path looks like very smooth sailing) Request/response validation, OpenAPI spec, fetch & react-query clients without any additional effort. Mocks for tests auto-generate based on contract definition as MSW. It almost feels too good to be true.