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

91–100 of 104 posts

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

#91

Post by dimgl »

ehutch79 wrote: post #69
ivanb wrote: post #66

It looks like one poor choice leading to another poor choice. They probably chose Prisma because it may have helped them with GraphQL, whereas they most likely don't need any GraphQL at all. Then they are screwing around with AWS Lambdas and package size, but what is the advantage of the Lambdas if they don't make your deployment easier? Just have a ECS and run whatever you want for better price/performance ratio and…

Your last sentence nails it. They’ve been sold a bunch of tools by tech influencers. Told that if you don’t use X you’re doing it wrong. They believed the hype. It’s hard to remember that, at this point, most tech influencers are shitposting or are full of shit.

The thing is that they themselves are tech influencers. So it's not surprising this article is the way it is. https://www.youtube.com/watch?v=J2j1XwZRi30

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

#92

Post by CharlieDigital »

spion wrote: post #60
CharlieDigital wrote: post #52

Earlier quoted context omitted.

.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.

Absolutely.

Rebranding would have helped in sooo many ways, even for the devs that moved forward from .NET Framework.

For starters, it would have at least made search results less confusing and more contextual. There were years of confusion between .NET Framework, .NET Standard, .NET Core, and .NET 5. From a basic SEO perspective, rebranding would have been huge.

It was a huge mistake to not rebrand it entirely.

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

#93

Post by richbell »

dncornholio wrote: post #78
francislavoie wrote: post #10

Earlier quoted context omitted.

With foreign keys, I can't use https://github.com/github/gh-ost for zero downtime migrations. Instant deal breaker, because schema changes are inevitable given business evolution.

Then don't use it. A migration tool that has no foreign key support is not a good migration tool. And it's even a worse reason to tell other people FK's are bad.

GitHub famously has a hard time managing their database and it's a source of frequent outages. Though, to be fair, they're also working with a massive volume of traffic.

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

#94

Post by evanelias »

francislavoie wrote: post #10
leononame wrote: post #6

Earlier quoted context omitted.

That is a strange take tbh. For me, ensuring data integrity at the database level gives me a lot of peace of mind. Migrations are actually safer and easier because the database will complain if something's wrong, and at the application level I can do an opportunistic insert and if the FK is not valid, I'll get an error, which is really nice if I don't need the related record at all so I don't need to fetch it first.

With foreign keys, I can't use https://github.com/github/gh-ost for zero downtime migrations. Instant deal breaker, because schema changes are inevitable given business evolution.

There are other options for zero downtime schema changes in MySQL and MariaDB.

You can use the database's built-in support for instant DDL (algorithm=instant) for adding and dropping columns. And then use Percona's pt-online-schema-change for all other cases, since it supports foreign keys.

Or if you're using a physical replication setup -- for example AWS Aurora without any traditional binlog replicas -- you can get away with using the database's built-in "online DDL" (algorithm=inplace, lock=none) for quite a few other cases. Historically the main problem with that method is that it causes replication lag, but that's a non-issue if you're not using logical replication in the first place. So then you only need to fall back to pt-osc for the rarer ALTER cases which don't support online DDL.

MariaDB 10.8+ also has an option called binlog_alter_two_phase, which can allow you to use online DDL without causing much replication lag.

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

#95

Post by twh270 »

CharlieDigital wrote: post #45
porbelm wrote: post #27

People needing to query huge amounts of data discovering technology that's been developed over the past 45 years for querying huge amounts of data efficiently; news at 11. Seems all these shops starting out with MongoDB or the like always need to do a huge, complicated migration to a /proper/ optimized data store, when they could have started with a sane design in the first place...

> People needing to query huge amounts of data discovering technology that's been developed over the past 45 years for querying huge amounts of data efficiently; news at 11 I think a lot of folks are quick to discount just how scalable a database like Postgres or SQL Server can be (not to mention battle tested). Maybe its because of a lack of DBMS experience as we've move more and more from owning database servers to…

Also, SQL is sCaRy. It's "hard to learn", and "we'll need experts to tune the database queries", and "schema migrations are a nightmare", etc.

Whereas MongoDB is "simple".

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

#96

Post by jamincan »

leononame wrote: post #11

> Further inspecting, we discovered that your code never makes the actual DB call. Your Prisma code performs a GraphQL network request (?) to the Prisma Rust query engine, which then translates your request into actual DB calls. I haven't used Prisma past fiddling with it a bit and this is extremely surprising to me. I guess it stems from Prisma's history but to me it's really off-putting and I don't think I'd use it…

They have a number of tools to consolidate queries into a single transaction (createMany in this case), or, you can control transactions directly using their $transaction api.

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

#97

Post by freddref »

brightball wrote: post #56
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…

Sometimes the toy becomes the full implementation.

yes hopefully, that's the best scenario.

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

#98

Post by freddref »

rewmie wrote: post #39
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…

> 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. On the flip side, the cases where the toy ends up being promoted to production service end up being riddles with technical debt, missing features, and buggy behavior that jeopardizes the whole project, also happen. Survivorship bias is also a major problem. It'…

This scenario emerges as often when starting from the toy as it does starting from the "correct" full implementation.

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

#99

Post by c0n5pir4cy »

thefilmore wrote: post #12

I tend to reach for TypeORM. It supports every database under the sun.

TypeORM is great and all - but it has its own quirks too and it's not a silver bullet.

In their case they would also maybe run into some issues as TypeORM has some initialization cost (building a model in memory when it first connects to the DB etc), some object mapping costs and other complexities (particularly around efficient query generation).

While there is nothing stopping it from working in a Lambda this would increase initialization time and cost which both matter since this is for a GraphQL API. I think the solution they've selected (Kysely) is probably a better fit.

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

#100

Post by ohthatsnotright »

superwalker wrote: post #90
Exuma wrote: post #33

Wow just one look at this issue was all I needed to see. https://github.com/prisma/prisma/discussions/12715 “Please open an issue if something really is unusable or breaks in any way so we have these concrete cases recorded. In our knowledge Prisma works just fine and returns the data that was requested, just using a different method.” Good lord

I substantially regret using Prisma in production for this and very many other reasons. At least the underlying data is well modeled, just need to rip out the JS library and replace it… but with what?

I found MikroORM [0] to be quite reasonable if you're in the TS ecosystem already. It was also easy to do custom, raw queries, and really just felt like it wasn't in the way.

[0] https://mikro-orm.io/

Post reply on HN