[discussion] Why trpc?

[mubaidr]

This is just discussion regarding the usage of TRPC, I feel like TRPC serves minimum purpose here.

I know that trpc brings type safety for api fetch endpoints, but so does native Nuxt api endpoints. (except the body types, which are planned to be introduced in future).

But I don't think this is enough reason to add complexity or add a whole new learning curve to Nuxt ecosystem, including:

• context passing is more complex when TRPC is sued with Nuxt
• Understanding the flow is more expensive
• integration with nuxt plugins and middlewares

I suggest, we remove TRPC from this stack to make it more native to Nuxt users, with less complexity overall and easier/ smooth onboarding.

I am also willing to create pull- request if interested.

P.S. Thanks for the awesome template. This stuff is awesome!

[JavascriptMick]

Hi @mubaidr

Thanks for the feedback. Hope you can get some use out of the template.

in short, I use it to provide an interface to the service layer that is completely agnostic to whether it is running on the client or the server... AND is fully typesafe front to back. This allows the template to support both SPA and SSR style pages with one common service interface. It's not a crazy approach for a framework of this sort, case in point the very popular react/next framework https://create.t3.gg/

Does it add complexity... yes Does it confuse some beginners.... yes Could you rip out Trpc (and Pinia) and still use the template... yes, I guess, I suppose you could replace it with restful endpoints and fetch for fetching data client side (if you needed SPA style pages) or just access the service layer from the setup method (if you were happy with just SSR pages) If you raise a PR to remove it from the template entirely, will I merge it.. No :)

More Information...

I explain my thinking behind using trpc in this video https://www.youtube.com/watch?v=AFfbGuJYRqI

and here is my explanation from the readme... Trpc over REST - Primarily for full thickness types without duplication on the client. Also I think the remote procedure call paradigm works well. Note however that I still include a REST endpoint example for flexibility. My preference for mobile is Flutter and there is not a Trpc client for Flutter that i'm aware off so it was important for me to make sure REST works also.

[mubaidr]

Appreciate your point of view!

in short, I use it to provide an interface to the service layer that is completely agnostic to whether it is running on the client or the server... AND is fully typesafe front to back. This allows the template to support both SPA and SSR style pages with one common service interface. It's not a crazy approach for a framework of this sort, case in point the very popular react/next framework https://create.t3.gg/

Nuxt native endpoints does support both SSR & SPA mode. I got feeling from this paragraph that Nitro does not.

The only difference I see (or advantage of TRPC over Nitro endpoints) is typesafety for request data/ input (more on this on previous comment). While output/ result has typesafety built in Nuxt/ Nitro.

Anyway, anyone can just strip out TRPC and use this template. It is still awesome! Thanks again.

[JavascriptMick]

@mubaidr you are right, Nuxt provides data fetching approaches that support both client and server environments but the payload is not typed. Using Trpc, particularly in conjunction with Prisma Typing to give me this super slick workflow when actually smashing in features to your SaaS...

Imagine, you are want to make the notes feature better.. You want to add an additional property to notes.. say colour.. 1) add colour property to the Note model in schema.prisma..

model Note {
  ....
  colour               String

2) update the database, and Prisma Models with one command

npx prisma db push

3) go to dashboard.vue and hover over line 12

const { notes } = storeToRefs(notesStore);

... the items in the notes array have a colour property that you can just use... no changes to api endpoints, no changes to type definitions, no changes in the service layer, no changes in the store... the Prisma Type change just pushes through all of those layers....In practice, this workflow is super productive and allows you to bang in new features ridiculously fast.

[mubaidr]

Except the payload thing, everything is valid with Nuxt/ Prisma setup too.

One more thing that bothered me while using TRPC there is no official support. Trpc team supports next, astro etc but won't name Nuxt anywhere.

But anyway, if it works it works.