Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

We migrated to SQL. Our biggest learning? Don't use Prisma

codedamn.com

Post reply on HN
Print view View original

51–60 of 104 posts

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#51

Post by Tade0 »

mattacular wrote: post #48
Tade0 wrote: post #41

I kind of want to say "y-yeah" regarding Prisma, because all this information (especially the fact that it creates a transaction every time and downloads those engines) is either available in the documentation or visible upon install/build - you can actually make it point to specific executables instead of downloading each time using environment variables but again - it's in the docs. I picked Prisma because I'm not…

> The lack of rollbacks Could you elaborate on this part?

Here's a comment from their team about this:

https://github.com/prisma/prisma/discussions/4617#discussion...

Tl;dr it's a design decision, not everyone (including me) agrees.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#52

Post by CharlieDigital »

jeswin wrote: post #49

Warning - opinions ahead. I've use a bunch of ORMs (in various languages) over the last two decades. Imho, one stands distinctly above the others - Microsoft's Entity Framework (EF). EF does something fundamentally different, while the rest are all some version of Hibernate with a different API or Programming Language. EF converts your code into SQL with the help of the compiler, and is not purely a runtime affair. T…

.NET and EF Core is the platform that most teams probably want but .NET and C# can't quite shake it's pre-Core image.

It always strikes me as odd that teams can embrace GitHub, TypeScript, and VS Code and then react negatively to C# and .NET being Microsoft platforms.

EF Core is perhaps the most powerful, most mature ORM at this point. .NET Web APIs are incredibly productive and performant with really good DX. C# isn't that far off from TypeScript syntactically and structurally.

I feel like teams that are "graduating" from TypeScript on Node probably want C# on .NET but end up exploring Go or Rust instead.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#53

Post by spion »

estebarb wrote: post #43
spion wrote: post #14

I would modify this to "Don't use Prisma if you're using serverless" With actual servers and prisma running close to the underlying database, it should be much better. Regarding using joins, that's not necessarily the best choice either. When using simple flat joins naively, you get a lot of repetition for the more toplevel nodes of the join tree, which eventually adds up to a lot of network traffic and allocation. (…

The joins should be done inside the DB, not in an external server. Any SQL DB should be able to do that.

If this is not done carefully, it can also be slow in some situations, even with the right indeces in place. Lets say we have the following slightly contrieved case:

organizaiton(id, name, description) -> users(id, name) -> posts(id, content) -> comments(id, userId, content)

We want to get one organization with all its users. Lets imagine our org has 100 users, each of which has 100 posts on average, each of which has 100 comments on average. In a naive, flat join, we'll be repeating the organization description column 1 million times, and each post's content about 100 times on average.

This can still be problematic without joins, as sending 1 million comment IDs in a query to the DB isn't going to work, so even the multiple queries version will need to do better than that

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#54

Post by jeswin »

city41 wrote: post #50
jeswin wrote: post #49

Warning - opinions ahead. I've use a bunch of ORMs (in various languages) over the last two decades. Imho, one stands distinctly above the others - Microsoft's Entity Framework (EF). EF does something fundamentally different, while the rest are all some version of Hibernate with a different API or Programming Language. EF converts your code into SQL with the help of the compiler, and is not purely a runtime affair. T…

Knex is probably the closest thing js has to this. It's not an orm though, just a query builder.

Knex is quite different iirc.

I was saying that ORMs should make use of parsers and modern language features (such as first class functions) to offer a unified interface to collections in memory and collections in the db. Essentially treating the table as a list on which you can use operators you're already familiar with.

By doing so, your core API is timeless. Because you didn't invent an API.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#55

Post by berkes »

CharlieDigital wrote: post #31
freddref wrote: post #18

Earlier 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…

I have a directory on my drive called `sandbox` where I basically throw together small toys for anything with some unknown complexity. Anything from how an ORM might model a specific type of relationship (throw together a basic replica with a Docker compose file) to replicating the deployment model (poking AWS Copilot, for example) to testing out some tooling flow (e.g. local build process change). The main thing wit…

I too have this "sandbox" directory. I use it for what you say. But also for troubleshooting, bugreports or a stackoverflow question.

Just throw up a new project, hack around in it for an hour, and most often the problem/bug in my original code becomes apparent because of the isolation. I'll easily write four such sandbox projects per week.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#56

Post by brightball »

freddref wrote: post #18
CharlieDigital wrote: post #5

Maybe it's just me, but if I'm doing any sort of migration like this, the first thing I do is create a small PoC that emulates the full process to iron out any weird, obvious edge cases and ergonomic issues. In this case, hitting the Lambda size limit would have been the first red flag that triggered a re-evaluation of the whole approach. Understanding the limits of the stack (Prisma + PlanetScale) would have been ob…

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…

Sometimes the toy becomes the full implementation.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#57

Post by w0m »

freddref wrote: post #18
CharlieDigital wrote: post #5

Maybe it's just me, but if I'm doing any sort of migration like this, the first thing I do is create a small PoC that emulates the full process to iron out any weird, obvious edge cases and ergonomic issues. In this case, hitting the Lambda size limit would have been the first red flag that triggered a re-evaluation of the whole approach. Understanding the limits of the stack (Prisma + PlanetScale) would have been ob…

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.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#58

Post by w0m »

CharlieDigital wrote: post #31
freddref wrote: post #18

Earlier 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…

I have a directory on my drive called `sandbox` where I basically throw together small toys for anything with some unknown complexity. Anything from how an ORM might model a specific type of relationship (throw together a basic replica with a Docker compose file) to replicating the deployment model (poking AWS Copilot, for example) to testing out some tooling flow (e.g. local build process change). The main thing wit…

'scratch' for me. Everything from quick regex tests to full library rewrites tend to start there.

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#59

Post by kjuulh »

jeswin wrote: post #49

Warning - opinions ahead. I've use a bunch of ORMs (in various languages) over the last two decades. Imho, one stands distinctly above the others - Microsoft's Entity Framework (EF). EF does something fundamentally different, while the rest are all some version of Hibernate with a different API or Programming Language. EF converts your code into SQL with the help of the compiler, and is not purely a runtime affair. T…

I've been burned by EF more times than I'd like, the most recent (it has been a few years), was the change in default to single queries, instead of split queries. Which absolutely destroyed our performance, until we figured we should turn single query off.

EF Core expression trees are nice, however, the change tracking behind the scenes are an absolute menace. I've gotten errors more times than I'd like, because EF Core had loaded a key in its store, and another query got the same key, resulting in an Exception because both touched the same record in the change tracker. Even if it was two separate requests.

I've become a purist sort of, using sqlc for golang, dapper for c# and sqlx for rust.

ORMs are 'fine' for simple crud apps, but once you go a bit deep in the sql, it becomes impossible to reason about. Telling an engineer that they can just run `explain analyze` on their query, and them having no idea how to actually reproduce their sql is not great.

This is also just my opinion, I've been in the same place, I used to love EF, but now I dread having to debug that stuff =D

Last time it was sending a non pointer to gorm in golang, panicing the application :,)

Re: We migrated to SQL. Our biggest learning? Don't use Prisma

#60

Post by spion »

CharlieDigital wrote: post #52
jeswin wrote: post #49

Warning - opinions ahead. I've use a bunch of ORMs (in various languages) over the last two decades. Imho, one stands distinctly above the others - Microsoft's Entity Framework (EF). EF does something fundamentally different, while the rest are all some version of Hibernate with a different API or Programming Language. EF converts your code into SQL with the help of the compiler, and is not purely a runtime affair. T…

.NET and EF Core is the platform that most teams probably want but .NET and C# can't quite shake it's pre-Core image. It always strikes me as odd that teams can embrace GitHub, TypeScript, and VS Code and then react negatively to C# and .NET being Microsoft platforms. EF Core is perhaps the most powerful, most mature ORM at this point. .NET Web APIs are incredibly productive and performant with really good DX. C# isn…

MS should've dropped the .NET branding once it became cross-platform.
Post reply on HN