Prisma'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 <a href="https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/query-engine/" rel="nofollow">https://www.prisma.io/docs/reference/tools-and-interfaces/pr...</a> for more info on this arrangement.<p>It has some weird ramifications though:<p>- 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: <a href="https://github.com/prisma/prisma/issues/2432" rel="nofollow">https://github.com/prisma/prisma/issues/2432</a><p>- 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 <a href="https://github.com/prisma/prisma-client-js/issues/349" rel="nofollow">https://github.com/prisma/prisma-client-js/issues/349</a> for more info on that<p>- 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)<p>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?<p>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.<p>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.
I 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.<p>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.<p>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.<p>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.
I'm super excited about Prisma 2! I feel like we finally have a database client that (1) is/will be very powerful and (2) is very approachable and easy for beginners to learn.<p>It certainly doesn't replace the need to know some SQL, but it does delay that which is great for so many people.<p>I'm definitely using this instead of any ORM for every project I can.<p>I really love having the fully typed interface for Typescript. Both for static type checking and for code completion in your editor.<p>We are using Prisma 2 as the default database client for Blitz.js [1] which results in a super nice stack. Especially because the Prisma DB types flow all the way into your React components.<p>[1] <a href="https://blitzjs.com" rel="nofollow">https://blitzjs.com</a>
If I understand correctly, transactions are currently not supported for doing any advanced business logic beyond building CRUD: <a href="https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/transactions#future-transaction-support-in-prisma-client" rel="nofollow">https://www.prisma.io/docs/reference/tools-and-interfaces/pr...</a><p>Also, no mention of aggregations, or if someone could point me to it?<p>As far as typed query builders go, even though things like JOOQ are simply amazing, but I fear that the query building approach has not really caught on for database access and people seem to prefer "object oriented" methods like ORMs.<p>Any comments from HN folks about why that is?
For those of you who prefer talks over blog posts to learn about new tools, I recently gave a talk introducing Prisma 2.0 and demoed how you can use it to build a REST API <i>and</i> a GraphQL API with a PostgreSQL database.<p>You can find the full recording here: <a href="https://www.youtube.com/watch?v=AnJxKWQG_fM" rel="nofollow">https://www.youtube.com/watch?v=AnJxKWQG_fM</a>
Not sure I 100% agree with their problem statement.<p>> the problem: Working with databases is difficult<p>Working with databases is a relatively solved problem. You can access them from just about any language on any platform. A more accurate statement would be: choosing the right access method to work with databases is difficult.
"The problem: Working with databases is difficult"<p>This makes me think of all brainstorming sessions I attended in my life with people asking over and over again, not convincing themselves with most answers: "Ok, guys, seriously now, what problem do we think we solving here?"
I'm really excited about Prisma and how it's contributing to the Node.js ecosystem. Two new full-stack frameworks, Redwood and Blitz, are based on it, and it's prominently mentioned in their READMEs. <a href="https://github.com/redwoodjs/redwood" rel="nofollow">https://github.com/redwoodjs/redwood</a> <a href="https://github.com/blitz-js/blitz" rel="nofollow">https://github.com/blitz-js/blitz</a><p>As a status announcement, this isn't quite as exciting as it sounds because migrations are still "experimental". Still great to see!
For those who rather work in GO checkout Super Graph its an automatic a GraphQL to SQL compiler. It works as a library or a standalone service. Also supports variety of auth schemes like Rails cookies, JWT, Firebase, etc. Super Graph auto-learns your database schemas and relationships. <a href="https://github.com/dosco/super-graph" rel="nofollow">https://github.com/dosco/super-graph</a>
I 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?
I found Prisma 2.0 good for prototyping a service serving a GraphQL-compliant API. One of the features not mentioned here is that it supports a rudimentary form of database query batching (see: <a href="https://github.com/prisma/prisma-client-js/issues/153" rel="nofollow">https://github.com/prisma/prisma-client-js/issues/153</a> ), and there seems to be interest in improving it.<p>This helps one with solving the nplusone problem to some extent without having to maintain code specifically for DataLoader + some orm / custom query code. Comparatively, code via the Prisma Client API is usually straightforward and succinct.
Does it have migrations yet?<p>I'd like to give Prisma a try, but if there's no sane way to change my schema (part of my daily backend workflow) then it's less interesting, no matter how nice the API is. For now I'll stick with Sequelize.
I love the idea of a type safe interface to a database, but I'll pass on learning yet another DSL. Seems like inevitably you get to a certain complexity and the DSL just falls apart and you wind up writing SQL regardless. Then you end up with half your queries written in one language (SQL) and the other half in the ORM DSL. SQL isn't that hard and if you are using a SQL database, you can't really escape knowing the concepts behind SQL relationships regardless which is the tricky bit.<p>So, bring on type safe access, but don't make me learn yet another DSL which only works 70% of the time.
I've been using the beta for the past couple months on a new project along with @nexus/schema to build a GraphQL server. This hits a sweet spot for me where I'm not having to manually duplicate a bunch of information in my GraphQL schema that's easily derivable from my database schema, but I still have the freedom to implement custom resolvers and use Prisma directly (or whatever else) when I need to. It's a good stack for building a GraphQL server around a Postgres db.<p>The main problems I've run into have been around utilizing standard postgres naming patterns (snake case for tables and fields instead of camelcase) and mapping the names in the prisma schema. Ran into a handful of bugs related to having these mappings that have all been fixed since. It still requires a post-introspect step to add the mappings, but that's not too big of a deal. Ideally the introspection would be able to handle database-specific conventions.<p>Couple of other things I've run into that already have github issues:<p>- It would be great if along with the create/connect options on relationships for nested writes there was also an upsert.<p>- Better transaction support beyond just nested writes would be great and probably a requirement for a lot of apps. Thankfully, my server is relatively simple right now so banking a bit on prisma improving as my app grows in complexity.
Any to solve the SQL long string problem? I hate having to write another custom SQL migration script beside Prisma migration script.<p>For your reference: <a href="https://github.com/prisma/prisma/discussions/2138" rel="nofollow">https://github.com/prisma/prisma/discussions/2138</a>
A thread on this from a couple months ago: <a href="https://news.ycombinator.com/item?id=22739121" rel="nofollow">https://news.ycombinator.com/item?id=22739121</a>
So with Prisma 2.0 I could replace <a href="https://www.npmjs.com/package/schemats" rel="nofollow">https://www.npmjs.com/package/schemats</a> + <a href="https://sqorn.org/" rel="nofollow">https://sqorn.org/</a> ?
I have a lot of experience with ORMs (the Django one in particular). I'm having a hard time finding a quick overview of how Prisma's model is different. Are there any good overviews of the similarities and differences?
I happened across Prisma recently while looking for a (more) declarative way of managing SQL migrations. It's far from complete, but a nice feature.
i'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