Reasons to avoid Prisma — ryanmr blog

Prisma is a pretty popular (1.5 million weekly downloads!) ORM for the Node ecosystem. I’ve used it at work in various small projects due to its purported popularity. After having had it in our ecosystem for over around months, I have some thoughts: 1. It uses a proprietary schema file format The `prisma/schema.prisma` format on its own is *fine*. … However, it is not easily open to extension or analysis by other ecosystem tooling that would be brought by JSON, YAML or TOML. Despite that, this blog knows how syntax highlight these code blocks, so I suppose that’s good enough. Either way, it irks me that it’s not in a generic format or in an actual programming language format (JS / TS). 2. Primsa requires a particular environment variable for database connections … However, this configuration isn’t in *your app code*. That means you can’t compose your credential string using what’s available in your app’s purview. In our cases, we’re using docker deploying to a kubernetes cluster that automatically injects various `DATABASE_` environment variables. Our setup doesn’t precompose `DATABASE_URL` with username and password inlined, so instead we need to use a custom `entrypoint.sh` that concatenates all these variables together so its suited for Prisma. 3. Thousands of issues … Having not kept any records from my previous encounters researching odd bugs and looking for generally useful features, I can’t say how many issues are noise or how many are pleas for features stuck in limbo. We all know what you say about open source though, of course, “PRs welcome.” Still, it’s never a good sign when your database connector, effectively the most foundational component of your application (after all, if you could not fetch or save data, would you even have an application?) is has so many issues tied to it. As an amusing example Ever use AsyncLocalStorage? Well, with Prisma that kind of just… breaks? There’s an alleged workaround but it could end up causing a memory leak. Surely, all of that is superfluous but it’s someone’s plan that’s just been ruined, superfluous or not. 4. Bonus! Bundling Prisma with a Next app in Standalone Mode (output settings) is tricky … Now, the actual query experience? It’s fine. For me the first 80% of an ORM is to handle simple `SELECT` `INSERT` `UPDATE` `DELETE` queries. Then everything else is probably object relational mapping. You can read all about the Object-relational impedance mismatch. There’s always going to be a weird situation where you need to write your own raw SQL (with a prepared statement, hopefully). I think it’s *good* to expose the object mapping utilities back to the user so they can rebuild the interface themselves, but most ORMs do not go out of their way for that.