Replies: 2 comments
-
Three major pros over REST and GraphQL:
If you want to play around yourself check https://stackblitz.com/github/trpc/trpc/tree/next/examples/standalone-server?file=src%2Fserver.ts,src%2Fclient.ts&view=editor and more info on the latest alpha of trpc which also has refactoring: https://github.com/trpc/trpc/blob/next/.tmp/v10-docs.md |
Beta Was this translation helpful? Give feedback.
-
tRPC is a bulky framework with overcomplicated API. Something like integrated Zodios would be much nicer IMO. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
Uh oh!
There was an error while loading. Please reload this page.
-
tl;dr: tRPC might be too new and too much of a breaking change to make it the default but it might be also an opportunity and should be discussed before we reach 1.0
SvelteKit did many right design choices re REST its implementation (shadow endpoints, same router/nice integration with page endpoints, etc.) but I find REST still exhausting and all work-arounds re type safety and DRY stay work-arounds. GraphQL is no option either because it adds bloat, decision fatigue, code gen or other non-DRY means and—the biggest bummer—another type system while TS has perfectly its own. Hence, tRPC might hit the sweet spot here.
tRPC has minimal integration efforts providing full native type safety and the opportunity to detach API routing from the folder structure which is intuitive but cumbersome to refactor and to deal with IRL.
I don't want to debate the pros and cons of REST, GraphQL and tRPC (which we can't ignore entirely) but rather question if REST is really the right default for v1.0.
Beta Was this translation helpful? Give feedback.
All reactions