Earlier quoted context omitted.
I suggest to not add a layer. Stay close of the SQL request, you can simply have a function that will fulfill an access pattern. No need for ORM.
Yeah, I have no problem with minimum ORM (prepared statements type of thing) - That's why I am asking the question, Prisma seems a bit too much. Usually I just use simple ORM helpers (get by primary key for example) and anything complex is raw sql. What I am looking for is ideally something that helps with type saftey and seeds/migrations/schema creation.
Prisma – ORM for Node.js and TypeScript
21–30 of 260 posts
Re: Prisma – ORM for Node.js and TypeScript
#22Re: Prisma – ORM for Node.js and TypeScript
#23- The generated client is top-tier. Fully specified in TypeScript with intelligent types that can be extended by the user.
- The schema language is great. It provides a cohesive experience that can fully express your database structure, and it also provides a migration framework to manage that structure's evolution.
- There's no hook for implementing access control at the model level, so you end up needing to create a higher-level API around the base queries to implement these yourself, which is a fairly large investment. I'd love to see a pair of functions that can modify the query before it gets sent to the Prisma engine to add extra query values, and a second function that can filter models before they are returned to the caller.
Where Prisma falls short is in testing. The testing story in Prisma is that you can either use a live database, or you can completely stub out all calls to Prisma in your application. The latter means you end up writing a bunch of tests for implementation rather than for behavior, or you end up manually writing an in-memory database that fits the Prisma API. The former means that you need to completely recreate your database after every test case.
The discussions on the Github seem to indicate that the old "wrap the test in a transaction" trick is forbidden, and Prisma seems architecturally set up to ensure that you can't even hack this behavior in.
All in all, we probably won't switch away from it, but I will continue to look for a better way to test my endpoints.
Re: Prisma – ORM for Node.js and TypeScript
#24I don't have much experience with node.js, so this question might sound silly. I don't see anything about database support in the blog post. Is Prisma enough to work with a PostgreSQL database from node.js? If not, what else am I missing?
Re: Prisma – ORM for Node.js and TypeScript
#25I LOVE Prisma. I’ve used Django, SQLAlchemy, Sequelize, Knex, and TypeORM in the past. all had rough edges that continually frustrated me or didn’t provide the functionality i needed. Prisma is different. It’s absolutely got rough edges, but the extremely strong type safety makes Sequelize look like a joke. The query engine itself, written in rust, combines and optimizes queries inside every tick of the event loop so…
Huh, care to explain this one? I’m using Prisma with Apollo Server without doing anything fancy in my resolvers. I just assumed I’m getting N+1 issues but didn’t bother to optimize yet.
Re: Prisma – ORM for Node.js and TypeScript
#26“ Application developers should care about data – not SQL” Anyone who has been bitten by an ORM generating inefficient SQL (and subsequent having to learn and care about SQL) knows the above not to be true.
I think the answer of whether to use one depends on the type and load/volume of app you're working with combined with the dynamics, size, and skill level of your team(s). I'm extremely comfortable writing, profiling, query planning, and debugging SQL queries. Others aren't, and therefore having an ORM to query data in the DB with the syntax of the language you're using in your projects makes way more sense, if nothing other in order to speed your team up.
Re: Prisma – ORM for Node.js and TypeScript
#27Edit: After quickly going through the intro, I prefer MikroORM, it's simpler.
Re: Prisma – ORM for Node.js and TypeScript
#28I LOVE Prisma. I’ve used Django, SQLAlchemy, Sequelize, Knex, and TypeORM in the past. all had rough edges that continually frustrated me or didn’t provide the functionality i needed. Prisma is different. It’s absolutely got rough edges, but the extremely strong type safety makes Sequelize look like a joke. The query engine itself, written in rust, combines and optimizes queries inside every tick of the event loop so…
This one I will believe when I see it. It would be a general solution to cache invalidation.
Re: Prisma – ORM for Node.js and TypeScript
#29I LOVE Prisma. I’ve used Django, SQLAlchemy, Sequelize, Knex, and TypeORM in the past. all had rough edges that continually frustrated me or didn’t provide the functionality i needed. Prisma is different. It’s absolutely got rough edges, but the extremely strong type safety makes Sequelize look like a joke. The query engine itself, written in rust, combines and optimizes queries inside every tick of the event loop so…
> GraphQL N+1 issues are a thing of the past. Huh, care to explain this one? I’m using Prisma with Apollo Server without doing anything fancy in my resolvers. I just assumed I’m getting N+1 issues but didn’t bother to optimize yet.
Re: Prisma – ORM for Node.js and TypeScript
#30“ Application developers should care about data – not SQL” Anyone who has been bitten by an ORM generating inefficient SQL (and subsequent having to learn and care about SQL) knows the above not to be true.
SQL is an impressive technology and has stood the test of time! Yet, we claim that it's not the best tool for application developers who are paid to implement value-adding features for their organizations.
SQL is complex, it's easy to shoot yourself in the foot with and its data model (relational data / tables) is far away from the one application developers have (nested data / objects) when working in JS/TS. Mapping relational data to objects incurs a mental as well as a practical cost!
This is why we believe that in the majority of cases (which for most apps are fairly straightforward CRUD operations) developers shouldn't pay that cost. They should have an API that feels natural and makes them productive. That being said, for the 5% of queries that need certain optimizations, Prisma allows you to drop down to raw SQL and make sure your desired SQL statements are sent to the DB.
I see Prisma somewhat analogous to GraphQL on the frontend, where a similar claim could be: "Frontend developers should care about data, not REST endpoints". GraphQL liberates frontend developers from thinking about where to get their data from and how to assemble it into the structures they need. Prisma does the same by giving application developers a familiar and intuitive API.