201–210 of 260 posts
Earlier quoted context omitted.
to wit: how exactly does Prisma make money?
https://news.ycombinator.com/item?id=26888735
I’ve been using Prisma for a while and I quite like it. Best ORM for TypeScript I’ve used. My biggest issue with it is testability. Sure, I can mock the Prisma client in tests with Jest or something, but if I want to test state I pretty much have to reimplement an in-memory DB using JS mocks. I can also connect to a real DB made for testing but it’s quite overkill, I’m usually not interested in testing Prisma itself,…
Thanks for this feedback. We're very aware of this problem and are are actually working on a guide for working with Jest right now. It's a tricky problem because our use of the type-system is quite complex. I quite like your idea of a test mode or maybe a mock client that we generate.
Or maybe just invest in this: https://github.com/oguimbal/pg-mem/issues/27 He has already put a lot of effort into it and I think with just a bit more support he can support Prisma
I don't like ORMs, but Prisma is one of the better ones. It avoids a lot of shortcomings of popular ORMs. I hope they find a way to make it work as a company. I've been following them over the years from the beginning of their journey through various pivots. To use an ORM effectively you must learn both the API of the ORM and SQL. It does not absolve you from learning SQL, which I think was one of the unstated attrac…
That is fundamentally wrong - or at least - it is very limiting.
Think very hard about adopting a framework that tries to shield you from SQL. Because at the end of the day, you will be looking at SELECTS and INSERTS in your logs because you are wondering why things are so slow or why your memory usage skyrockets.
It looks like Prisma allows you to go to raw SQL if you must, yet you won't have a good time using some of PostgreSQL more advanced features.
If your domain model is simple and will remain simple in the future, then - by all means - use a builder that creates queries from your domain model. Use a single-source-of-truth approach that is usable from the back-end and front-end.
In other cases, where your domain model changes over time, be very careful when choosing an ORM but extra double careful in picking the right data store.
Earlier quoted context omitted.
The first thing I've looked at on your site is how migrations work. Because honestly, I think that's one of the best things about Django. They just got it right, and as you say, not many other tools get close. I wonder if you have looked at how it works. Because they have put in something like a decade to make it work and it's very powerful and a joy to use. Down migrations are indeed very useful and important once y…
Yep we looked at Django ORM as an inspiration. I unfortunately don't have the bandwidth right now to write a lengthy thoughtful response, but quickly on a few points: - The replaying of the migrations history is exactly what we do, but not in-memory, rather directly on a temporary (shadow) database. It's a tradeoff, but it lets us be a lot more accurate and be more accurate, since we know exactly what migrations will…
Django doesn't try (too hard) to validate your model against the actual DB schema. Because why would it? You either ran all the migrations and then it matches or you didn't and then you have to. (Unless you write your own migrations and screw them up. But that's rare and you can catch it with testing.) While your focus then seems to be to check if the schema (whatever is there in the db) matches the model definition. Based on my experience (as a user) this latter is not really something that I need help with.
Data is actually an issue in development and hard resets + (re)seeding is pretty inconvenient compared to what django provides. E.g. in my current project we're using a db snapshot that we've pulled from production about two years ago (after thorough anonymization, of course). We initialize new dev environments and then it gets migrated. It probably takes about half a minute to run as opposed to about 2 seconds of back migrating 2-3 steps.
I would love to try Prisma otherwise.
Can someone compare to Hasura please? What has been your experience?
I use Hasura and generally like it, it certainly has some sharp edges, but overall has worked. I think Hasura has much richer GraphQL support, which I pair with gqless[0] to get what I think is a much nicer client side / ORM experience overall. Other upsides are a much better RBAC column/row permissions, migrations with up/down, a better admin UI. [0] https://gqless.com
I find that with new tech, I'm more interested in what it can't do rather than what it can.
Earlier quoted context omitted.
> I normally wouldn't call out an individual library to shit on, because I understand that a lot of work has gone into it. I don't think I've ever called out on a library, or not felt truly thankful that it was there to help me. But Sequelize... man... When I first got into Node, and got Sequelize, after working for years with .NET, Entity Framework, NHibernate and the likes, it just felt like horrible-everything. I'…
Same. Honestly, I only have not-nice things to say about Node, JavaScript, and its ecosystem, so I should probably just shut up. But I was like you- I picked up Node because we had an existing project in it. It only used libraries that had the most "stars" or whatever on NPM and they were all pretty deficient (and some were shockingly slow). But none were so frustrating as Sequelize.
The NPM ecosystem can be frustrating and annoying sometimes but today nodejs is a solid server runtime.