https://www.prisma.io/ logo
Join Slack
Powered by
Lets say i have a monrepo, i have introspected mod...
# orm-help
k
Lets say i have a monrepo, i have introspected models from the database and they now live in schema.prisma.
Copy code
backend/
  prisma/
    schema.prisma
frontend/
I wanted to share types between the frontend and backend and because its a monorepo i can simply create 
shared
folder.
Copy code
shared/
backend/
frontend/
if i want to reuse types that are generated by Prisma in the frontend whilst also using them in the backend, how might i do this? Does this even make sense to do, "should" i move the prisma stuff over to the shared directory? Or should i really be creating a new seperate type for my api responses, even though in majority of the cases im simply returning a 1:1 of table columns and object fields.
✅ 1
a
basically you can set up a config file that points to your BE schema and generate the queries you need for the front end
once generated - the FE should be able to consume all the models/input types as well without the need to duplicate code
for non-graph QL there are other code gen options to consider but it depends on the type of API you are trying to craft
k
Im not using graphql
a
the other tools for example would be RPC definers such as https://github.com/palantir/conjure where you can declare shared types and have both consume the packages generated
k
I think youre missing the point of my question, it wasen't just about how do i share types between frontend and backend
a
Ok so part 1 is covered right? Part two to clarify is ‘should I do this’ and what is the best practice?
j
Regardless of whether it's a GraphQL or a RESTful API, we always define the static types of the DTOs for request+response schemas in a shared pattern between server+client. This requires using an SDK for RESTful APIs, but for GraphQL with Apollo you get it for free, which is one of the primary reasons REST is an outdated dinosaur. In either situation, the DTOs are defined 100% independently from the Prisma schemas. Explicit > implicit here, because implicit makes it too easy to leak sensitive information. Serialization to an explicit DTO schema hugely reduces this possibility, you would have to be maliciously incompetent to make this mistake with explicit separate schemas.
👍 2
Also, in any real-life platform, you are going to find it a HUGE pain in the ass if you try to do it implicitly, because the DB schema changes all the time, but the API surface MUST NOT change.
Having explicitly separate schemas with a serialization layer means I'm free to change the DB schema however I want to without changing the API surface.
So there are a lot of very similar types in the Prisma generated types and the DTO types, but this is one of the many situations where you would only be hurting yourself to try to DRY it up, in many cases duplicated code is definitely what you want, eliminating duplication makes your code empirically worse and harder to maintain (in these specific situations where each of the 2 duplicates actually represent two different surfaces)
8 Views
Open in Slack
PreviousNext
Powered by