#API communication between frontend and backend
54 messages · Page 1 of 1 (latest)
Instead of using nestjs-trpc, which is not actively maintained yet,
https://github.com/KevinEdry/nestjs-trpc/issues/69#issuecomment-3030338288
consider usingts-restas an alternative.
ts-restoffers official support forNestJS.
Hi @atomic sluice , you mean, some sort of common folder where DTOs or interfaces are shared between back and front? Am I right?
@atomic sluice I landed in using nestjs/swagger to be able to expose an openapi endpoint. The in my frontend repository I’m using Orval as the openapi client generator. There are many like Orval but found it quite intuitive and well maintained. Shouldn’t be a problem to rip it out and just go with something else down the line
I use https://github.com/hey-api/openapi-ts, it forces me to properly create my openapi specs
@atomic sluice https://github.com/Rykuno/SojuStack here's how i do it. Read the e2e typesafe section in the readme
thanks guys for the people who jumped in with these suggestions
im going to check all these out shortly
i found nestjs-zod and drizzle-zod to have actually helped anybody used these since im using drizzle for orm i found an official package called drizzle-zod which allows you to create zod scehams from db tables, meaning i can use those as my dtos and frontend dtos like under one dto
@zealous osprey you have a really solid repo right here.
i was integrating better auth seems like you setup your own custom one and not use the nestjs-better-auth package.
yeah so this is a good way ofc. with the current setup i had i was planning to have the drizzle-zod package be the source of truth whcih basically creates zod schemas based on the drizzle type so its like having the db as the source of truth.
You get way more control over auth if you just throw the auth config in a service class. To me, there is 0 reason to use an external package that just arbitrarily abstracts things you don't want abstracted away from you
true and tbh the maintainer has been so so slow
at updates,
ill consider using ur setup for better auth instead.
so for configuring the auth api routes does the better auth handle mounting the route handlers
Also his way has you disabling body parser globally which you generally need
yeah
Yep
nice nice
dude thats sick
glad i came across it
hope you dont mind me pinching at you here and there lol
im using react router v7 on the frontend
just cuz tanstack still in beta and this projcet is for prod so yeah
Start is in beta, tanstack router is v1
im also using nestjs-zod for data validation / transformation i saw ur using class-transformer and class-validator
so im able to create dtos from zod schemas.
but in my case im creating dtos from drizzle-zod which is from the db type.
You usually don’t wanna create dtos tied to your database objects
interesting
im trying to figure out the right setup tbh
atm slightly lost
i dont want to manage to many types between frontend and backend
what do you reckon is a good appraoch
i have setup nestjs workflow from setting up custom exeception layer to catching errors to validation pipe which uses zodValidationPipe to validated data incoming in a route handler to be of the dto
Nest is already an opinionated ecosystem well tested. You’d be surprised at how easy and clean things are if you stick with the “nest way”
interesting so you mean sticking to class-validator and class-transformer
for validation
which is the reccomened validation schema.
Yep
got you okay.
i think it also helps
when defining the open api spec
swagger likes it more.
and on the frontend when using react hook form for example
which validation schema do you combo it with
i know shadcn form component is really good but usally needs a schema to work off of
so if i use class-validator for example i think i would need to create a seperate schema for the form on the frontend.