trpc

[devinschumacher]

my buddy (developer) Brian recommends we use https://trpc.io/docs

let's look into it @dawaltconley

[dawaltconley]

I'll have to read more, not immediately sure what the advantage is since Nuxt is all Typescript & useFetch picks up on the API types, but they do have a Nuxt example: https://trpc-nuxt.vercel.app/

[devinschumacher]

Im a bit unclear as well, maybe brian can clarify

@2-fly-4-ai

[2-fly-4-ai]

I'll have to read more, not immediately sure what the advantage is since Nuxt is all Typescript & useFetch picks up on the API types, but they do have a Nuxt example: https://trpc-nuxt.vercel.app/

Hey mate, I'm coming from next trying to see how things fit together. I just took a look at the template, and the current way of doing things looks clean. No need to shoehorn in TRPC if it is not prevalent in the nuxt/vue ecosystem but it's very useful and part of the other stacks I use. So maybe just take a look.

What are you using for your validations? Have you considered Zod? Or is there some better way to use nuxt? It's another great tool that helps me a lot with forms and other things. I find it very useful. let me know.

Here is the implementation of trpc I was looking at before. I started from here as they have a nextjs t3/turbo repo setup and a nuxt one. So was just comparing the way they do things there are a lot of similarities.

https://github.com/devinschumacher/supastarter-nuxt/blob/main/packages/api/modules/admin/procedures/delete-user.ts

This is very much my current stack at the moment. Fan of working in monorepos, but it depends on the scope of the project and if you need a mobile version etc.

What are you currently using for UI? Have you used shadcn at all? That is my current go-to as well. I see there is a Nuxt version; I'm gonna start experimenting tomorrow and getting familiar with Vue. But it all looks pretty similar.. Should be quick.

https://github.com/devinschumacher/supastarter-nextjs
https://create.t3.gg/
https://github.com/t3-oss/create-t3-turbo

[devinschumacher]

@2-fly-4-ai

• ✅ yes, we are implementing Zod for data validation -- see add to README #51 -- it's in the queue for Milestone 1 to add to the proj!
• ✅ yes, we will be using shadcn for UI as well -- see Milestone 3

[devinschumacher]

Marking this as cancelled - seems the consensus is we do not need trpc.

[devinschumacher]

My research into trpc over nuxt's useFetch is this:

Benefits of tRPC instead of just useFetch:

• Reduced Runtime Errors: Type safety catches mismatches and errors during development rather than at runtime.
• Improved Collaboration: Developers can work confidently on different parts of the app, knowing that shared types prevent miscommunication.
• Faster Development: Auto-generated types and APIs reduce the amount of boilerplate code and speed up feature development.
• Easier Maintenance: Changes to data models are automatically reflected throughout the codebase, simplifying updates and refactoring.

Key Takeaways

Type Safety with useFetch:

• Limited to Client Side: Any type annotations are only checked on the client and do not guarantee that the server's response matches.
• Manual Maintenance: Requires you to manually ensure that client-side types match server responses.

Type Safety with tRPC:

• End-to-End Enforcement: Types are shared between client and server, providing true end-to-end type safety.
• Automatic Updates: Changes on the server automatically propagate to the client, reducing maintenance overhead.

TLDR

"If you value the end-to-end type safety and streamlined API development that tRPC provides, it's worthwhile to incorporate it into your Nuxt project alongside useFetch."

@dawaltconley

[2-fly-4-ai]

Trpc is the shit. I would recommend It. I don't know enough about nuxt to make this assertion confidently. But from my experience in full stack web deb, it is unmatched when it comes to implementing crud in any application,,

…

On Sat, Oct 19, 2024 at 10:31 PM Devin Schumacher ***@***.***> wrote: My research into trpc over nuxt's useFetch is this: Benefits of tRPC instead of just useFetch: - Reduced Runtime Errors: Type safety catches mismatches and errors during development rather than at runtime. - Improved Collaboration: Developers can work confidently on different parts of the app, knowing that shared types prevent miscommunication. - Faster Development: Auto-generated types and APIs reduce the amount of boilerplate code and speed up feature development. - Easier Maintenance: Changes to data models are automatically reflected throughout the codebase, simplifying updates and refactoring. Key Takeaways Type Safety with useFetch: - Limited to Client Side: Any type annotations are only checked on the client and do not guarantee that the server's response matches. - Manual Maintenance: Requires you to manually ensure that client-side types match server responses. Type Safety with tRPC: - End-to-End Enforcement: Types are shared between client and server, providing true end-to-end type safety. - Automatic Updates: Changes on the server automatically propagate to the client, reducing maintenance overhead. TLDR "If you value the end-to-end type safety and streamlined API development that tRPC provides, it's worthwhile to incorporate it into your Nuxt project alongside useFetch." @dawaltconley <https://github.com/dawaltconley> — Reply to this email directly, view it on GitHub <#56 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/A2Y2TP3O3TFQFHEPBDHSZQTZ4IYJ3AVCNFSM6AAAAABPCUYKUCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDIMRTG42DQNBQG4> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[devinschumacher]

moving this to another milestone since we dont really know what to use it for yet anyways