194 karma · joined February 4, 2015
The level of type-safety when using Prisma Client with TypeScript is indeed a major factor that sets Prisma apart from other DB libraries in general (not Massive in particular).
Would also love to hear what other people think of the two in comparison! :)
What I'm mostly trying to refer to are ActiveRecord style ORMs in the Node.js ecosystem (such as Sequelize and TypeORM). With those libraries, you often have model objects that can get really complicated to work with, these are not plain objects but implement lots of additional behaviour for storage and retrieval of data, often times business logic as well. Compared to that, working with plain objects (which are statically and structurally typed) is a fundamentally different approach that's hopefully easier to reason (at least that's what I've found from my personal experience).
See my response above:
> Also note that you can actually generate Prisma Client into a different location [4], so if you prefer not to have it in node_modules, that's totally possible as well.
[4] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
TLDR: Generally deployment should "just work", but there can be cases when you might have to do some extra configuration to get your app deployed.
Also note that you can actually generate Prisma Client into a different location [4], so if you prefer not to have it in node_modules, that's totally possible as well.
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[2] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[3] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[4] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
However, using Nexus [1] on top of Prisma, you'll be then be able to turn Prisma's realtime API into GraphQL subscriptions. All of this is quite a bit further down the road, but certainly on our radar and part of future plans!
We have an open feature request for that here: https://github.com/prisma/prisma/issues/298
Prisma is a database toolkit that's used by application developers to develop server-side applications in Node.js and TypeScript (e.g. REST APIs, microservices, gRPC calls, GraphQL APIs, ..., anything that talks to a database). The main tool Prisma Client is a query builder that's used to programmatically send queries to a database from Node.js/TS.
Hasura is a "GraphQL-as-a-Service" provider that generates a GraphQL API for your database. This GraphQL API is typically accessed by frontend developers. That setup can be great when your application doesn't require a lot of business logic and the CRUD capabilities that are exposed in the GraphQL API fit your needs (though I believe you can add business logic in Hasura by integrating serverless functions).
With Prisma, you're still in full control of your own backend application and can choose whatever tech stack you like for developing it (as long as it's Node.js-based, though Prisma Client will be in available in more languages the future)!
By the way, we also love GraphQL. We're currently brewing a new "GraphQL application framework" that can be used on top of Prisma. That way it will be possible to auto-generate resolvers for Prisma models to reduce the boilerplate you need to write, while still keeping the full control of your GraphQL schema.
You can learn more about this here: https://www.nexusjs.org/#/
If you have a specific DB in mind that you'd like to see supported, please open a feature request here: https://github.com/prisma/prisma/issues/new?assignees=&label...
More info here: https://www.prisma.io/docs/more/faq#how-much-does-prisma-20-...
You can find more context on isprisma2ready.com.
The most important thing to note here is that Prisma Client is not an ORM! [1]
Prisma doesn't map classes to tables as ORMs do and therefore doesn't suffer from the object-relational impedance mismatch. Prisma Client queries return plain old JS objects, which makes it really easy to reason about queries and returned data.
Prisma also has a query engine [2] that's implemented in Rust. This is being developed separately from the TS/JS layer above (so that in the future Prisma can support other languages as well).
Prisma also generally provides stronger type safety than TypeORM. For example, you get full type safety even for partial queries [3], you can find an example for what this looks like in this video [4].
Let me know if you have more questions about this :)
[1] https://www.prisma.io/docs/understand-prisma/prisma-in-your-...
[2] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[3] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
For people who want to learn more about using Prisma together with Nexus (which enables exposing DB models via GraphQL), I also recommend checking the next iteration of Nexus that we're currently working on (which will turn into a fully-fledged GraphQL application framework with TypeScript as a first-class citizen): https://nexus-future.now.sh/#/
Let me know if you have any questions!
> It seems to take a lot of inspiration from the mongo api
That's an interesting comment but I'm not sure it's quite accurate. I think where we're taking quite a bit of inspiration from MongoDB is the idea of "thinking in objects" because this is much closer to the mental model developers have when they work with data. We are currently already working on an improved API of Prisma Client [1] that looks less like MongoDB but should feel a lot more ergonomic.
Regarding your example of removing the `where` from a `findOne` call. In this case it's needed because you can also select/include [2] fields and/or relations:
await prisma.users.findOne({
where: { id: 1 },
include: { posts: true }
})
await prisma.users.findOne(1).load({ include: { posts: true } })
I just want to stress that Prisma is not an ORM! ORMs are characterized by the fact that classes are mapped to tables and you have complex model instances that carry logic for storage, retrieval, serialization, deserialization and often custom business logic. Prisma does none of that! It provides an auto-generated and fully type-safe database client that's tailored to your database schema. Any data you'll ever retrieve is fully typed and comes in the form of plain old JS objects that a are easy to reason about.
> prisma tries to do migrations, table creation, etc, etc. These things rarely work properly.
I'd love to learn more about where you think Prisma's migrations approach falls short! IMHO moving towards a dclarative migration system based on an intuitive data modelling language is much closer to how developers are thinking about their data than using SQL migrations. One of our users once described it like this:
"What Prisma does for migrations is essentially what React does for rendering. A user need only describe the current state, but not the operations to get to that state. So, thank you for doing this to databases as React (and others) has for UIs!"
> Lazy loading never works. Somewhere litered in your code you access a field that is outside the scope of the pulled in data and it is in a loop and suddenly you have 100 requests.
Do you mind elaborating how/where you see this problem happening in Prisma?
> There are security issues with ORMs that traverse and save relationships, as github itself found out.
Again, Prisma is not an ORM and I have a hard time seeing how this applies to it.
> ORMS should just be for fairly simple, single table tasks. That way they get out of the road and don't become some big complex thing that ruins performance and adds its own complexity.
I fully agree with this poinit and it's one of the core desiign goals of Prisma. If you feel Prisma doesn't achieve this, we're doing something wrong...
All that being said, I really appreciate your thoughts and feedback and would love to see you in the Prisma Slack [3] and sharing your thoughts in our GitHub issues.
[1] https://github.com/prisma/specs/issues/356
[2] https://github.com/prisma/prisma2/blob/master/docs/prisma-cl...
Feel free to reach out to me: burk@prisma.io or @nikolasburk on the Prisma Slack https://slack.prisma.io
You can also find examples for the various use cases here: https://github.com/prisma/prisma-examples/tree/prisma2
Please let me know if that clarifies it or if you have more questions! :)
For anyone that wants to check out what we're up to, you can find everything you need in this repo: https://github.com/prisma/prisma2
However, I've never understood why people write this mapping code manually. I believe in code generation tooling as a potential solution for this (where types and maybe a full data access API is auto-generated based on the database schema).
Most ORMs are heavily inspired by object-oriented programming which fosters the object-relational impedance mismatch. In addition to logic for storing and retrieving data, models often also implement business logic (ActiveRecord is a good example here). This makes for bloated and complex objects that are difficult to work with in the application. A solution can be to lower the level of abstraction and use a more lightweight query builder (like knex.js for Node.js). These kind of tools give you more control in constructing your queries as well as the ability to optimize them.
These tools still require you to understand quite a bit of SQL though and the productivity leap compared to writing manual SQL isn't as high. I believe that query builders are the best compromise we have today for accessing a database from an application.
Regarding the dual schema dangers that are mentioned by the author, I strongly believe that these can be alleviated using code generation tooling that helps to keep your database in sync with your application models (approaches like SQLBoiler in Go where application code is generated based on the database schema are an example here).
- Heavy ORMs: Object-oriented mapping layers that map classes to tables. A record is represented as an object that not only carries data but also implements various behaviours for storage, retrieval, serialization and deserialization of its own data, sometimes it also implements business/domain logic. Examples: ActiveRecord, EntityFramework, Hibernate, Sequelize, ...
- Lightweight query builders: Lightweight, programmatic abstractions on top of SQL. Examples: knex.js, pypika, ...
There are issues with both approaches.
Heavy ORMs
Heavy ORMs make it seem like a developer doesn't need to know SQL to work with a database. They help to get a project off the ground quickly, but as a project grows and requirements become more complex, they often generate slow queries or generally lack capabilities to express the right queries. After all, a developer will be forced to understand what's going on in the SQL layer underneath, spending a lot of time debugging and understanding the generated queries, often without the possibility to optimize them. The premise of "not knowing SQL" and productively working with database longterm has just been proven wrong in so many cases (I feel like everyone has been burnt by an ORM at least once in their dev career...).
Lightweight query builders
Lightweight query builders on the other hand don't try to abstract too much away from SQL. Their APIs typically use SQL terminology and they're not trying to hide the fact that they're working with a database. Coming from an application developers perspective, there still is the drawback that you must have a solid understanding of SQL to work with them efficiently. Another issue that these query builder APIs typically aren't type-safe. There's no static analysis that can help identify typos or other issues in the DB queries you're building. In terms of developer experience, they lack features like autocompletion for DB queries. Personally, I still prefer query builders over heave ORMs since I get more control.
Time for a plug: I work at Prisma where our mission is to make it easier for application developers to work with databases by providing developer-friendly, efficient and performant abstractions and tools for working with database! We're currently building the Prisma Framework [1] which consists of two main tools:
- Photon [2]: A lightweight, auto-generated and type-safe database client
- Lift [3]: A tool for declarative data modeling and database migrations
You can learn more about both tools in this blog post: https://www.prisma.io/blog/announcing-prisma-2-zq1s745db8i5/
Both tools are based on the Prisma schema [4], a declarative abstraction over your database schema that serves as foundation for the generated Photon API. Lift migrations work by mapping the Prisma schema to your database schema. We also build a ton of other nice tools and libraries that simplify database workflows (such as Prisma Studio, a database GUI) or integrations with API layers, such as GraphQL Nexus [5] for building type-safe GraphQL APIs without boilerplate.
To get started, check out this tutorial: https://github.com/prisma/prisma2/blob/master/docs/tutorial....
[1] https://github.com/prisma/prisma2
[2] https://photonjs.prisma.io/
[4] https://github.com/prisma/prisma2/blob/master/docs/prisma-sc...