Prisma 2.0 – Type-safe and auto-generated database client
1–10 of 112 posts
Re: Prisma 2.0 – Type-safe and auto-generated database client
#2i'm not a node dev, but am seeing the activerecord (from rails) inspired ideology behind this. while activerecord certainly has its downsides, its awesome upsides/ideas should definitely be reused
Re: Prisma 2.0 – Type-safe and auto-generated database client
#3I empathize with the frustration that this library is trying to solve. It's pretty nifty too! Ultimately, however, I don't believe this is the correct approach.
The problem with this tool, like every other multi-SQL-flavor-SQL ORM and query builder, is that it requires users to learn yet another language. In addition to Node.js and SQL, users need to learn the Prisma query language. This is not trival, and users that are already accustomed to working with SQL will need to relearn PrismaSQL.
I think the best approach to this problem is a single-SQL-flavor query builder that attempts to match SQL as closely as possibly while adding in the niceties of being able to pass in JavaScript objects instead of raw SQL strings. Lets be honest: raw SQL-in-JS is no fun.
This would lead to PostgreSQL, MYSQL, SQLite, etc-specific query builders. Knex is close, but it ultimately doesn't work for most because it's missing some language-specific features (e.g. ON CONFLICT DO UPDATE). While this doesn't exactly meet the type safety benefits of Prisma, the benefits in ease of use and feature-parity of a language-specific query builder far outweigh the difficulties of learning a new query language like Prisma.
Re: Prisma 2.0 – Type-safe and auto-generated database client
#4I don't have my head in backend too much these days and haven't kept up with all of these solutions. It seems like Hasura is the more popular option right now? or do they fit a slightly different space?
Re: Prisma 2.0 – Type-safe and auto-generated database client
#5I empathize with the frustration that this library is trying to solve. It's pretty nifty too! Ultimately, however, I don't believe this is the correct approach. The problem with this tool, like every other multi-SQL-flavor-SQL ORM and query builder, is that it requires users to learn yet another language. In addition to Node.js and SQL, users need to learn the Prisma query language. This is not trival, and users that…
TypeORM? Zapatos maybe?
Re: Prisma 2.0 – Type-safe and auto-generated database client
#6I empathize with the frustration that this library is trying to solve. It's pretty nifty too! Ultimately, however, I don't believe this is the correct approach. The problem with this tool, like every other multi-SQL-flavor-SQL ORM and query builder, is that it requires users to learn yet another language. In addition to Node.js and SQL, users need to learn the Prisma query language. This is not trival, and users that…
Nikolas from the Prisma team here, thanks a lot for your comment!
> The problem with this tool, like every other multi-SQL-flavor-SQL ORM and query builder, is that it requires users to learn yet another language. In addition to Node.js and SQL, users need to learn the Prisma query language. This is not trival, and users that are already accustomed to working with SQL will need to relearn PrismaSQL.
I'm not sure I'd fully agree with this! The "other language" in this case is an intuitive and natural API (in Node.js/TypeScript) for querying data [1], so hopefully, there won't be much overhead to "learn" anything new. It should be rather the opposite and pretty straightforward to pick up, auto-completion and type-safety will also contribute to making the experience of querying data fluent without much learning overhead.
We specifically decided to abstract away from SQL because we found that many developers don't feel productive with SQL as their main database abstraction [2] (that's also why so many people roll their own data access layers in the end).
> I think the best approach to this problem is a single-SQL-flavor query builder that attempts to match SQL as closely as possibly while adding in the niceties of being able to pass in JavaScript objects instead of raw SQL strings. Lets be honest: raw SQL-in-JS is no fun.
It sounds like your thinking is generally aligned with ours actually! The main difference is that we concluded that the query builder shouldn't be SQL-flavored but just a natural API for any Node.js or TypeScript devs.
[1] https://www.prisma.io/blog/announcing-prisma-2-n0v98rzc8br1#...
[2] https://www.prisma.io/docs/understand-prisma/why-prisma#appl...
Re: Prisma 2.0 – Type-safe and auto-generated database client
#7Prisma's architecture seems novel and ... a little strange to me. It works by running a Rust engine as a subprocess and then communicating with the engine from JS land over a non-spec compliant GraphQL API. The engine holds the actual databae connection pool and does all the SQL generation and data marshalling. See https://www.prisma.io/docs/reference/tools-and-interfaces/pr... for more info on this arrangement.
It has some weird ramifications though:
- when they go to implement a new feature (like recently added JSON column support) they have to implement it on both sides which can cause bugs like this: https://github.com/prisma/prisma/issues/2432
- they're a little limited to the semantics of GraphQL based RPC, which namely excludes any stateful stuff like arbitrary START TRANSACTION; blocks that might or might not commit. See https://github.com/prisma/prisma-client-js/issues/349 for more info on that
- they don't run everywhere JavaScript runs like the browser or Cloudflare Workers (unless there's something fancy that compiles the engine to WASM I'm not aware of)
I wonder if their intention is to re-use the engine between different JS processes for caching / sharding or something like that, or to add Prisma clients in other languages. Why create the indirection?
I do like Prisma's type safety compared to the pure TypeScript alternatives like TypeORM and MikroORM -- it's really good at typing the results of specific queries and preventing you from accessing stuff that wasn't explicitly loaded. The style of the query language is the cleanest I've seen out of the three as well IMO.
Edit: I think node modules can install arbitrary binaries to some serverless JS runtimes, not sure specifically about Cloudflare but I know their dev tool bundles JS using webpack, which would exclude other binaries from node_modules.
Re: Prisma 2.0 – Type-safe and auto-generated database client
#8I don't have my head in backend too much these days and haven't kept up with all of these solutions. It seems like Hasura is the more popular option right now? or do they fit a slightly different space?
Prisma and Hasura are very different!
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/
Re: Prisma 2.0 – Type-safe and auto-generated database client
#9I don't have my head in backend too much these days and haven't kept up with all of these solutions. It seems like Hasura is the more popular option right now? or do they fit a slightly different space?
Having used both, I would pick Hasura for any project going forward. Time to productivity is so much faster with Hasura and “it just works”. Prisma, at least when I was using it, was introducing breaking changes regularly and whipsawing between major design choices.
Re: Prisma 2.0 – Type-safe and auto-generated database client
#10I don't have my head in backend too much these days and haven't kept up with all of these solutions. It seems like Hasura is the more popular option right now? or do they fit a slightly different space?
Prisma is a little bit lower level -- you'd use it within a node backend to get data to and from the database in a typesafe way. Hasura could be used for the same thing, but you'd have to spend some time setting up your own JS client to use within a backend to talk to Hasura. I think Hasura shines a bit more for powering client side apps directly, who just make GraphQL calls right to the "database" service.