https://www.prisma.io/ logo
Join Slack
Powered by
Hi guys. I'd like to use Prism for my next project...
# orm-help
k
Hi guys. I'd like to use Prism for my next project and wanted to know what backend framework (for a REST API) you'd recommend that works really well with TypeScript. Aside from Express (I'd like to try something new)
r
Fastify is a great alternative!
👍 1
s
Strongly recommend NestJS with Fastify!
👍 1
b
struggling with the same quest... re NestJS I stated my current thoughts here
r
Unfortunately there isn’t any REST generator for Prisma, for GraphQL you have a couple of options 🙂
k
I'm still new to using GraphQL in general, would the options support websockets as well or should I rely on GraphQL subscriptions in that case?
r
GraphQL subscriptions use websockets under the hood so that should be fine 🙂
b
Hm, I was under the impression that NestJS concepts apply regardless of REST vs GraphQL
or are you saying there are Prisma generators out there that build those DTO classes for me?
r
Yup, but for GraphQL. I have not yet seen a REST DTO generator but @Samrith Shankar might know more.
b
r
Awesome!
That should be a great starter for not create DTO’s manually.
✅ 1
b
true - but there remains the challenge that Prisma query responses are plan 
JSON objects
while NestJS relies on tools like class-transformer - expecting class instances. So you'd always have to duplicate memory usage for HTTP responses
s
I actually don't use DTOs. Never had the need for it with Prisma. For validation, I just use 
zod
b
I personally wouldn't need DTOs either (esp. for validation) - but the OpenAPI (Swagger) module in NestJS relies on those (must be classes) to represent models in the spec
s
Ah yeah, I actually have my APIs documented in Postman. Which automatically generates Swagger documentation form our body
b
that would involve manual steps to produce docs, right? How do you make sure that you cover all exposed endpoints?
s
So, currently I document all the endpoints manually. This is also majorly because my request body does not match my Dto/Model. In most cases I have custom structure which is easier for the frontend to read/understand, and a different naming for the backend.
b
understood. thanks
s
So basically in Postman, I have a collection where I add every endpoint as and when I create it with the body and then Postman generates the docs.
No problem!
b
are you aware that you can describe your output data in a DTO that doesn't match but is derived from your Prisma model in NestJS?
by that you'd still describe your output data as a class (which has to be manually authored in your case anyways) and reduce manual labor
s
Yes, but in my case, I specifically use Zod (or Joi or anything) for validation because I use 
react-hook-form
on the frontend. Which natively supports Zod objects for validation. 🙂
b
cool. I've always been rooting for superstruct in that case.
s
So basically I use the same validation "engine" on the backend and frontend. Also, so far, the manual addition of endpoints hasn't proved to be a very laborious process for us. Though I agree it can be simplified.
Superstruct and Zod are extremely similar. I publish my types from the backend as a private GitHub package, which every frontend depends on, and exposes all my backend API types. This way frontend can "discover" the API directly from the package. Plus implement validation on the frontend with it.
👍 1
b
are your zod schemas generated from Prisma schema or manually created?
s
Manually. Because our request body is nothing close to our Prisma schema.
Like for example: to create a payment card our model has the following fields:
Copy code
model PaymentCard {
  number String
  expiry String
}
But, from our frontend, our request which updates or creates them are like this:
Copy code
{
  amount: 123,
  cardNumber: 1243435324123423,
  cardExpiry: "2021-06-30T23:59:59.999Z"
}
a
Validation wise, I use https://github.com/sinclairzx81/typebox and ajv, fast, type safe, and infer type for me
👍 1
Open in Slack
PreviousNext
Powered by