> Every new insert via Prisma opened a database-level transaction (?). An extremely weird design choice by Prisma.
Isn't that standard practice for inserts?
We migrated to SQL. Our biggest learning? Don't use Prisma
101–104 of 104 posts
Re: We migrated to SQL. Our biggest learning? Don't use Prisma
#102Earlier quoted context omitted.
I am amazed at the number of engineers I've worked with who jump straight into the full implementation. I've done it myself on a few occasions thinking "how hard can this be". Building the "toy" first is great. In my experience, about one third of the time the toy is all you need, you can stop there, and what you were going to build fully would be over-engineering. About one third of the time, building the toy tells…
> In my experience, about one third of the time the toy is all you need, you can stop there In my experience, about two-thirds of the time management sees the toy and ShipsIt thinking that's all you need.
Exactly. That's why I don't build the toy anymore: Too many broken promises of "Yes, we won't put it into production until it's ready", and then my team is left maintaining a system in production that had no business of ever being in production.
Re: We migrated to SQL. Our biggest learning? Don't use Prisma
#103I’m using Prisma and PlanetScale and while I’ve been happy with PS, Prisma hasn’t been the best to work with. Especially in a serverless environment the engine size is painful. I’m able to work around it and I have a good amount of headroom still but I’d rather have that space back. For anything other than basic CRUD on a single entity or a few easy relationships I feel the need to write raw SQL. The DSL for Prisma’s ORM (schema is fine) is annoying and I feel like I’m fighting with it more often than not. Even once I have it working I’m not confident that it’s efficient at all, it worries me that the code “looks” simple (again it’s not easy to write in the first place) but isn’t.
I started with Aurora and DataApi and switched to Prisma and PlanetScale. I have every intention of staying with PlanetScale but I’ve considered rewriting my codebase to not use Prisma. All the raw queries would be easy enough and I think I’d be happier with a type safe query _builder_ instead of a full ORM but I could be wrong. I’m almost glad Prisma’s aggregate helpers are such trash since it made me just write my own queries instead of standing on my head to make Prisma’s work.
One thing I won’t miss is scouring my codebase for .prisma folders that might contain an outdated schema file that the engine is somehow picking up. I even have an npm script that I run to find and delete all but the main one I know is supposed to be there.
Re: We migrated to SQL. Our biggest learning? Don't use Prisma
#104You should really try out RDB, an ORM that I've been working on since 2014.
It has a very small fooprint - well suited for Amazon lambda. We now support client over HTTP (in a safe manner), making it accessible in-browser.
Key Features:
No code generation required
Full intellisense, even when mapping tables and relations
Powerful filtering - with any, all, none at any level deep
Supports JavaScript and TypeScript
ESM and CommonJS compatible
Succint and concise syntax
Works over http