Prisma feel like it leads to bad code design patterns
I’ve been learning and working with Prisma as I rewrite a project of mine in Typescript and one thing really stood out to me with it, it’s really easy to create complex queries and create / modify data from multiple places
Quick example, users can change settings in my project, that has the potential to happen from multiple places and if I made each one of those it’s own Prisma call with update, then if I ever wanted to add analytics to settings changes I’d have to go to each place and put an event listener
The way I’ve set up Prisma in my project is similar to how Discord JS handles their interactions, with managers and structures
If someone wants to update a user setting, that has to go through the user setting manager, this way there’s one single edit function so if I ever go to dispatch events on user settings change, I can be sure I’ll capture everything
Along with that, setting it up this way allows me to enforce rules on the codebase, for example no creating of foreign keys in Prisma queries, if you want to make an object you have to go through the manager to ensure all relevant events are fired
The reason I ask this is because I’m writing a lot of boilerplate on top of Prisma now to try to make in this style, while I’m somewhat happy with where I’m at with it, it also feels slightly wrong. I’m a bit torn on if this is dramatically over complicating things or a good approach for scaling my application.
I think for my project, my approach makes sense, with the trade off being the complexity of Prisma for a setup that I know will be scalable
How do you approach Prisma in your projects, do you have help functions, something more complex, or just raw queries throughout the code?
Here’s some code to help understand what I’m talking about, it’s a bit rough around the edges, just playing with ideas for it atm
Abstract classes:
Manager:
https://github.com/AnswerOverflow/AnswerOverflow/blob/Turbo-Repo-Base/packages/core/src/managers/manager.ts
Structure:
https://github.com/AnswerOverflow/AnswerOverflow/blob/Turbo-Repo-Base/packages/core/src/structures/base.ts
Implementation:
Channel settings manager:
https://github.com/AnswerOverflow/AnswerOverflow/blob/Turbo-Repo-Base/packages/core/src/managers/channel-settings/channel-settings-manager.ts
Channel settings structure:
https://github.com/AnswerOverflow/AnswerOverflow/blob/Turbo-Repo-Base/packages/core/src/structures/channel-settings.ts
Quick example, users can change settings in my project, that has the potential to happen from multiple places and if I made each one of those it’s own Prisma call with update, then if I ever wanted to add analytics to settings changes I’d have to go to each place and put an event listener
The way I’ve set up Prisma in my project is similar to how Discord JS handles their interactions, with managers and structures
If someone wants to update a user setting, that has to go through the user setting manager, this way there’s one single edit function so if I ever go to dispatch events on user settings change, I can be sure I’ll capture everything
Along with that, setting it up this way allows me to enforce rules on the codebase, for example no creating of foreign keys in Prisma queries, if you want to make an object you have to go through the manager to ensure all relevant events are fired
The reason I ask this is because I’m writing a lot of boilerplate on top of Prisma now to try to make in this style, while I’m somewhat happy with where I’m at with it, it also feels slightly wrong. I’m a bit torn on if this is dramatically over complicating things or a good approach for scaling my application.
I think for my project, my approach makes sense, with the trade off being the complexity of Prisma for a setup that I know will be scalable
How do you approach Prisma in your projects, do you have help functions, something more complex, or just raw queries throughout the code?
Here’s some code to help understand what I’m talking about, it’s a bit rough around the edges, just playing with ideas for it atm
Abstract classes:
Manager:
https://github.com/AnswerOverflow/AnswerOverflow/blob/Turbo-Repo-Base/packages/core/src/managers/manager.ts
Structure:
https://github.com/AnswerOverflow/AnswerOverflow/blob/Turbo-Repo-Base/packages/core/src/structures/base.ts
Implementation:
Channel settings manager:
https://github.com/AnswerOverflow/AnswerOverflow/blob/Turbo-Repo-Base/packages/core/src/managers/channel-settings/channel-settings-manager.ts
Channel settings structure:
https://github.com/AnswerOverflow/AnswerOverflow/blob/Turbo-Repo-Base/packages/core/src/structures/channel-settings.ts
Was this page helpful?
