12 ms·

Prisma 2.0 – Type-safe and auto-generated database client

210 points by Sujan 6y ago

volkk 6y ago
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
snowoutside 6y ago
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. 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.
- agustif 6y ago
  TypeORM? Zapatos maybe?
  - gmac 6y ago
    https://typeorm.io https://typeorm.io https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/
    - agustif 6y ago
      Yeah thanks I ever can't remember how to do markdown links so I don't even try
- nikolasburk 6y ago
  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#thinking-in-objects-a-natural-and-familiar-query-api https://www.prisma.io/blog/announcing-prisma-2-n0v98rzc8br1#... [2] https://www.prisma.io/docs/understand-prisma/why-prisma#application-developers-should-care-about-data--not-sql https://www.prisma.io/docs/understand-prisma/why-prisma#appl...
  - snowoutside 6y ago
    Thanks for your response Nikolas! Prisma's approach is well thought out, and I appreciate the new angle on an old and challenging problem. For Typescript users, especially new users, Prisma can be a big win. Abstracting SQL has huge benefits here (especially type safety/static analysis), and I look forward to seeing where this project goes. That being said, my favorite database is PostgreSQL because it has so many features (and I'm just comfortable with it). At some point, a tool like Prisma (or Knex, TypeORM, etc) just cannot support all PostgreSQL features because it needs to support other flavors too. While some users may find this trade off acceptable, I always find myself hacking around the tool to use the raw features. Therefore, my ideal environment would be a full-featured PostgreSQL query builder. TL;DR I see the benefits of Prisma, but they're not for me at this point
- ctrlplusb 6y ago
  I get where you are coming from, but from your comment I am guessing you have yet to try Prisma. I'll speak to my personal experience... I became allergic to ORMs after experiencing much of the pain that you describe. Like you, I quickly found ORMs were simply an additional domain language / abstraction over my database that provided more pain that usefulness. Every time I wanted to make I change to the code I had to wade through tons of docs and/or stackoverflow posts by other frustrated users. If I wanted type safety I had to express and maintain types/decoders/encoders myself. Huge pain, and things always got stale leading to a massive mistrust in my data layers. Prisma doesn't feel like those experiences. Their schema-first, client code gen approach works surprisingly well. Using the generated API feels really intuitive, and TypeScript is there the whole time providing guidance and autocomplete for me. The object tree query syntax is quite refreshing compared to the builder pattern approach taken by the alternatives. I always found the builder pattern overwhelming and often a guessing game at how to compose them. I think Prisma doesn't try to be too clever with their data API. They solve the 99% in a manner that is simple and convenient, for everything else you have the raw query API - much like other solutions. I'd suggest giving it a try. You may like it.
  - JamesBarney 6y ago
    That sounds awful, and completely different from my experience with ORMs. My experience has almost exclusively been entity framework, which despite having some warts (rank over partition queries are impossible) has been a very pleasant experience. One advantage is the additional domain language is also the language of array/list manipulation, and not having to maintain any encoders/decoders (I honestly don't know what these are).
    - ctrlplusb 6y ago
      The tax of untyped languages and/or simple/generic API abstractions over databases.
    - marcosdumay 6y ago
      Oh, there are two different kinds of ORM. You are talking about one where the goal is to make querying the database more idiomatic on your development language, at the cost of some flexibility. This works very well as long as you stay within the bounds of the abstraction, and breaks terribly when you step out of it. The engineering goal is to make the abstraction just broad enough to represent most of the common queries without making it less idiomatic. The second kind is the type that tries to abstract databases into a specialized query language. The goal here is to bring things you don't get on plain SQL (like type integration or a single DBMS independent language) without losing expressive power. That's the one the GP is talking about.
- gajus 6y ago
  Specifically in Node.js, https://github.com/gajus/slonik https://github.com/gajus/slonik has drastically improved the experience of writing and composing SQL queries. I am the author of Slonik.
  - SirensOfTitan 6y ago
    We use slonik and absolutely love it. Alongside polymode (for inline sql mode) in emacs it’s wonderful to use. Thank you for writing and maintaining such a great library.
- ssijak 6y ago
  JOOQ from jvm world is exactly that, typesafe sql with dsl pretty much the same as good ol’ SQL
- galacticdessert 6y ago
  What you descrive is very similar to Rezoom.SQL for F#. https://github.com/rspeele/Rezoom.SQL https://github.com/rspeele/Rezoom.SQL It has type checked queries in plain SQL (based on SQLite syntax), compile time consistency checks, autocomplete, schema migrations, and more. The normal queries have all the guarantees, but in case you might want to use some vendor specific features, it also has the option of vendor queries. Very very cool library.
- udfalkso 6y ago
  "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." You essentially describe Elixir's Ecto, which has been lovely to work with. You may want to check it out.
- albertgao 6y ago
  You need to try it 1st dude... There is no query based language, the runtime API is generated from your DB layer, and is fully TS/JS, so there is no new language to learn. It is just TS/JS. You don't know which API to use? Type a dot and all APIs is there, this is called Intellisense. So, it is not `like every other multi-SQL-flavor-SQL ORM and query builder` `I think the best approach to this problem is a single-SQL-flavor query builder that attempts to match SQL as closely as possibly`, you do not work with GraphQL, do you... Knex. I think Objection.js is much better.
jamil7 6y ago
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?
- nikolasburk 6y ago
  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/ https://www.nexusjs.org/
  - tirumaraiselvan 6y ago
    > 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). (I’m from Hasura) You can extend business logic in Hasura in a number of ways, including (but not exclusively) ones that work well with serverless and async architectures. Other examples follow: 1. You can extend it by adding business logic in the database via user-defined functions. Eg: You want a fulltext search or a PostGIS function that is better off in the DB anyway. 2. You can bring your own GraphQL server with custom resolvers and Hasura will merge them into its own API and let you “join” across them as well. 3. You can bring REST APIs and add graphql types for them in Hasura and use it as custom resolvers that extend the schema as well. Hasura’s key value add is an instant GraphQL API backed by your own data-sources (database, GraphQL, REST) and then a fine-grained authorization system on it. Like Nikolas said, very different from Prisma. Hasura aims to add value as “infrastructure” by guaranteeing performance and security where as Prisma is like an ORM/database toolkit.
hbrundage 6y ago
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 https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/query-engine/ 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 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 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.
- Sytten 6y ago
  A few things to note: - Prisma 1 was a completely independent server and Prisma 2 was most likely started as a rewrite of Prisma 1 so it followed the same approach - This indirection will be removed if someone can finally land a Rust binding to NAPI (looking at you Neon binding people) - Prisma plans to support multiple languages thus it makes sense to have an agnostic engine - This not far from having a PG engine coded in C and interfacing with like like most libraries do anyway, javascript is just too slow for this kind of stuff
davedx 6y ago
Does it have migrations yet? 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.
- gabrielizaias 6y ago
  They have, but it's "experimental" at the moment: https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-migrate https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
- nikolasburk 6y ago
  Today's release unfortunately doesn't include our migration solution Prisma Migrate [1] yet. We totally understand that a lot of people want to get "database access" and "schema migrations" with the same tool/library, that's why we're focusing most of our engineering efforts on Prisma Migrate next and will hopefully be able to release that soon! However, we do see a lot of folks using third-party migrations (like knex.js or indeed Sequelize) and then still get the benefits of Prisma Client [2] through introspection [3] for the time being. For non-critical applications we also already see lots of users who are trying out Migrate and help us improve it through constant feedback! I'd love to hear your thoughts on the current version so that we can make sure to consider your feedback and ideas for Migrate when building it out over the next few months. [1] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-migrate https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [2] https://www.prisma.io/blog/announcing-prisma-2-n0v98rzc8br1/#how-prisma-client-boosts-productivity-and-raises-confidence https://www.prisma.io/blog/announcing-prisma-2-n0v98rzc8br1/... [3] https://www.prisma.io/docs/reference/tools-and-interfaces/introspection https://www.prisma.io/docs/reference/tools-and-interfaces/in...
  - andrewingram 6y ago
    Is there a plan for a higher-level migration API rather than just generating + executing raw sql strings?
wiremine 6y ago
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?
- nikolasburk 6y ago
  I think one very common characteristic of most ORMs is that tables are defined in terms of classes (often called models). You then instantiate these classes to work with the model instances for data storage and retrieval. Prisma takes a fundamentally different approach by generating a database client that returns plain old JS objects. We've written more extensively about this topic in the docs: https://www.prisma.io/docs/understand-prisma/why-prisma https://www.prisma.io/docs/understand-prisma/why-prisma
- 2color 6y ago
  Daniel from the Prisma team here. Both Prisma and ORMs abstract away from SQL and let you "think in objects". However, how they do that is different. With ORMs, you typically map tables to model classes With Prisma, the focus is on queries and structural typing; queries return plain objects that are fully typed based on the query. For a broader comparison with ORMs, check out the documentation page about why Prisma is not an ORM: https://www.prisma.io/docs/understand-prisma/prisma-in-your-stack/is-prisma-an-orm https://www.prisma.io/docs/understand-prisma/prisma-in-your-...
  - wiremine 6y ago
    Cool, thank you very much!
hn_reddit_human 6y ago
If I understand correctly, transactions are currently not supported for doing any advanced business logic beyond building CRUD: https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/transactions#future-transaction-support-in-prisma-client https://www.prisma.io/docs/reference/tools-and-interfaces/pr... Also, no mention of aggregations, or if someone could point me to it? 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. Any comments from HN folks about why that is?
- ssijak 6y ago
  People are scared of SQL or they want to use their objects for data access, business logic and views at the same time (leading to bad architecture and headaches), or they come from Nosql world, or they want a shiny new tool, or they do not understand features of their used db well, or because “everybody is using ORM zyz”... Just from the top of my head, there are probably more.
- doug78 6y ago
  How can ORM be used with Prisma?
rodolphoarruda 6y ago
"The problem: Working with databases is difficult" 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?"
- nikolasburk 6y ago
  Scarily close to reality :D
  - sorenbs 6y ago
    :-P
mesaframe 6y ago
It's funny how suddenly everyone is moving towards types. A couple of years back which was frowned upon. And was seen as anti productive.
- ctrlplusb 6y ago
  True. A big appeal for me with TS is that the inference engine is decent, so doesn't feel too ceremonious, and I can also tap out of the type system at any point and write a bit more gnarly code. Typing just the boundaries can be super helpful sometimes.
- marcosdumay 6y ago
  If by "a couple" you mean 10 to 15, then yes, that's correct. Look at the modern type systems we have around and try to see how they are different from what was mainstream by that time.
  - mesaframe 6y ago
    I am not talking about the state of type system. But, how they were projected as one. Especially when dynamic languages were getting popular.
- deleted 6y ago
  [deleted]
jhanschoo 6y ago
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: https://github.com/prisma/prisma-client-js/issues/153 https://github.com/prisma/prisma-client-js/issues/153 ), and there seems to be interest in improving it. 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.
flybayer 6y ago
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. It certainly doesn't replace the need to know some SQL, but it does delay that which is great for so many people. I'm definitely using this instead of any ORM for every project I can. I really love having the fully typed interface for Typescript. Both for static type checking and for code completion in your editor. 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. [1] https://blitzjs.com https://blitzjs.com
- narrationbox 6y ago
  What are your thoughts on RedwoodJS? https://github.com/redwoodjs/redwood https://github.com/redwoodjs/redwood
  - flybayer 6y ago
    Great alternative if you don't care about Next.js and you absolutely want to use GraphQL.
visopsys 6y ago
Any to solve the SQL long string problem? I hate having to write another custom SQL migration script beside Prisma migration script. For your reference: https://github.com/prisma/prisma/discussions/2138 https://github.com/prisma/prisma/discussions/2138
andy_ppp 6y ago
The magic is great! Until it stops working in production...
TLadd 6y ago
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. 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. Couple of other things I've run into that already have github issues: - It would be great if along with the create/connect options on relationships for nested writes there was also an upsert. - 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.
- nikolasburk 6y ago
  Thanks so much for sharing your experiences with Prisma! > 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. Better re-introspection flows are indeed very much on our radar and something that we want to tackle soon! Would be great if you could leave a comment with your use case on GitHub [1], so we can make sure to address it properly when planning and prioritizing new features! :) > Better transaction support beyond just nested writes would be great and probably a requirement for a lot of apps. Same here! It would be really helpful for us if you could share some details about your use cases for transactions in the feature request [2] so that we can incorporate them in our planning and design of the feature! [1] https://github.com/prisma/prisma/issues/2425 https://github.com/prisma/prisma/issues/2425 [2] https://github.com/prisma/prisma/issues/1844 https://github.com/prisma/prisma/issues/1844
enahs-sf 6y ago
Not sure I 100% agree with their problem statement. > the problem: Working with databases is difficult 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.
- ronanyeah 6y ago
  Well said. Though Hasura makes it easier.
- arxpoetica 6y ago
  Agree to disagree. For certain kinds of programmers who tend to think more analytically, databases are easy to work with. For those of us who tend to think more visually or kinesthetically, I appreciate tools that are trying to solve problems at a less-lingual/code level.
  - albertgao 6y ago
    Isn't a DB naturally embrace 'visually'? I mean, there is a table. Every time I think of a table, I get a picture in my brain... xD
- ogre_codes 6y ago
  > A more accurate statement would be: choosing the right access method to work with databases is difficult. For me, it's the fiddly bit where you interface between the programming language and the database is a PITA.
  - nikolasburk 6y ago
    This is exactly how it's meant in the article btw!
nikolasburk 6y ago
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 and a GraphQL API with a PostgreSQL database. You can find the full recording here: https://www.youtube.com/watch?v=AnJxKWQG_fM https://www.youtube.com/watch?v=AnJxKWQG_fM
gsvclass 6y ago
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. https://github.com/dosco/super-graph https://github.com/dosco/super-graph
- gsvclass 6y ago
  Use it to replace your ORM in your own GO app. No more having to struggle with joins etc just describe the data in GraphQL and Super Graph will generate the SQL for you.
- nikolasburk 6y ago
  Just as a side-note, with Prisma we're planning to support more languages beyond the Node.js/TypeScript ecosystem. We're currently already working on a version of Prisma Client in Golang, you can see the first prototype and track the development on GitHub: https://github.com/prisma/prisma-client-go https://github.com/prisma/prisma-client-go
- newusertoday 6y ago
  this looks great do you know if anyone is using it in production?
  - gsvclass 6y ago
    Yup a few startups mostly using the standalone version. One even runs it alongside their Rails app on Google Cloud Run to add a high-performance graphql api to an existing Rails app. I'm speaking to a couple people who want to use it within their traditional GO REST API to query the database instead of using an ORM.
dang 6y ago
A thread on this from a couple months ago: https://news.ycombinator.com/item?id=22739121 https://news.ycombinator.com/item?id=22739121
benatkin 6y ago
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. https://github.com/redwoodjs/redwood https://github.com/redwoodjs/redwood https://github.com/blitz-js/blitz https://github.com/blitz-js/blitz As a status announcement, this isn't quite as exciting as it sounds because migrations are still "experimental". Still great to see!
olso 6y ago
So with Prisma 2.0 I could replace https://www.npmjs.com/package/schemats https://www.npmjs.com/package/schemats + https://sqorn.org/ https://sqorn.org/ ?
nahtnam 6y ago
Been using Prisma for a while. Nothing better than typing `await prisma.`, hitting ctrl+space, and having it autofill everything for you! :)
ogre_codes 6y ago
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. So, bring on type safe access, but don't make me learn yet another DSL which only works 70% of the time.
- albertgao 6y ago
  the DSL is only for table management, and pretty similar to GraphQL type definition The ORM layer is not a DSL but some nicely done JS/TS functions
  - ogre_codes 6y ago
    > The ORM layer is not a DSL but some nicely done JS/TS functions You are splitting hairs here as far as I'm concerned. You need to learn the an API so you can do 70% of your queries. Then you need to learn SQL so you can do the other 30% of your queries and actually understand how to design a database. The queries that the "nicely done JS/TS functions" are replacing are almost always the simplest, most basic queries. Do you really need a special query language to say `select * from widgets`? The big problem with every ORM layer is you are essentially learning a disposable language. Every ORM says it's the best way to Query ever, and yet here we are, 5000 ORMs later and SQL is still an essential skill for developers. I know... "This time it's different!".
OJFord 6y ago
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.

210 points by Sujan 6y ago

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

snowoutside 6y ago

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. 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.

agustif 6y ago
TypeORM? Zapatos maybe?
- gmac 6y ago
  https://typeorm.io https://typeorm.io https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/
  - agustif 6y ago
    Yeah thanks I ever can't remember how to do markdown links so I don't even try
nikolasburk 6y ago
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#thinking-in-objects-a-natural-and-familiar-query-api https://www.prisma.io/blog/announcing-prisma-2-n0v98rzc8br1#... [2] https://www.prisma.io/docs/understand-prisma/why-prisma#application-developers-should-care-about-data--not-sql https://www.prisma.io/docs/understand-prisma/why-prisma#appl...
- snowoutside 6y ago
  Thanks for your response Nikolas! Prisma's approach is well thought out, and I appreciate the new angle on an old and challenging problem. For Typescript users, especially new users, Prisma can be a big win. Abstracting SQL has huge benefits here (especially type safety/static analysis), and I look forward to seeing where this project goes. That being said, my favorite database is PostgreSQL because it has so many features (and I'm just comfortable with it). At some point, a tool like Prisma (or Knex, TypeORM, etc) just cannot support all PostgreSQL features because it needs to support other flavors too. While some users may find this trade off acceptable, I always find myself hacking around the tool to use the raw features. Therefore, my ideal environment would be a full-featured PostgreSQL query builder. TL;DR I see the benefits of Prisma, but they're not for me at this point
ctrlplusb 6y ago
I get where you are coming from, but from your comment I am guessing you have yet to try Prisma. I'll speak to my personal experience... I became allergic to ORMs after experiencing much of the pain that you describe. Like you, I quickly found ORMs were simply an additional domain language / abstraction over my database that provided more pain that usefulness. Every time I wanted to make I change to the code I had to wade through tons of docs and/or stackoverflow posts by other frustrated users. If I wanted type safety I had to express and maintain types/decoders/encoders myself. Huge pain, and things always got stale leading to a massive mistrust in my data layers. Prisma doesn't feel like those experiences. Their schema-first, client code gen approach works surprisingly well. Using the generated API feels really intuitive, and TypeScript is there the whole time providing guidance and autocomplete for me. The object tree query syntax is quite refreshing compared to the builder pattern approach taken by the alternatives. I always found the builder pattern overwhelming and often a guessing game at how to compose them. I think Prisma doesn't try to be too clever with their data API. They solve the 99% in a manner that is simple and convenient, for everything else you have the raw query API - much like other solutions. I'd suggest giving it a try. You may like it.
- JamesBarney 6y ago
  That sounds awful, and completely different from my experience with ORMs. My experience has almost exclusively been entity framework, which despite having some warts (rank over partition queries are impossible) has been a very pleasant experience. One advantage is the additional domain language is also the language of array/list manipulation, and not having to maintain any encoders/decoders (I honestly don't know what these are).
  - ctrlplusb 6y ago
    The tax of untyped languages and/or simple/generic API abstractions over databases.
  - marcosdumay 6y ago
    Oh, there are two different kinds of ORM. You are talking about one where the goal is to make querying the database more idiomatic on your development language, at the cost of some flexibility. This works very well as long as you stay within the bounds of the abstraction, and breaks terribly when you step out of it. The engineering goal is to make the abstraction just broad enough to represent most of the common queries without making it less idiomatic. The second kind is the type that tries to abstract databases into a specialized query language. The goal here is to bring things you don't get on plain SQL (like type integration or a single DBMS independent language) without losing expressive power. That's the one the GP is talking about.
gajus 6y ago
Specifically in Node.js, https://github.com/gajus/slonik https://github.com/gajus/slonik has drastically improved the experience of writing and composing SQL queries. I am the author of Slonik.
- SirensOfTitan 6y ago
  We use slonik and absolutely love it. Alongside polymode (for inline sql mode) in emacs it’s wonderful to use. Thank you for writing and maintaining such a great library.
ssijak 6y ago
JOOQ from jvm world is exactly that, typesafe sql with dsl pretty much the same as good ol’ SQL
galacticdessert 6y ago
What you descrive is very similar to Rezoom.SQL for F#. https://github.com/rspeele/Rezoom.SQL https://github.com/rspeele/Rezoom.SQL It has type checked queries in plain SQL (based on SQLite syntax), compile time consistency checks, autocomplete, schema migrations, and more. The normal queries have all the guarantees, but in case you might want to use some vendor specific features, it also has the option of vendor queries. Very very cool library.
udfalkso 6y ago
"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." You essentially describe Elixir's Ecto, which has been lovely to work with. You may want to check it out.
albertgao 6y ago
You need to try it 1st dude... There is no query based language, the runtime API is generated from your DB layer, and is fully TS/JS, so there is no new language to learn. It is just TS/JS. You don't know which API to use? Type a dot and all APIs is there, this is called Intellisense. So, it is not `like every other multi-SQL-flavor-SQL ORM and query builder` `I think the best approach to this problem is a single-SQL-flavor query builder that attempts to match SQL as closely as possibly`, you do not work with GraphQL, do you... Knex. I think Objection.js is much better.

jamil7 6y ago

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?

nikolasburk 6y ago
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/ https://www.nexusjs.org/
- tirumaraiselvan 6y ago
  > 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). (I’m from Hasura) You can extend business logic in Hasura in a number of ways, including (but not exclusively) ones that work well with serverless and async architectures. Other examples follow: 1. You can extend it by adding business logic in the database via user-defined functions. Eg: You want a fulltext search or a PostGIS function that is better off in the DB anyway. 2. You can bring your own GraphQL server with custom resolvers and Hasura will merge them into its own API and let you “join” across them as well. 3. You can bring REST APIs and add graphql types for them in Hasura and use it as custom resolvers that extend the schema as well. Hasura’s key value add is an instant GraphQL API backed by your own data-sources (database, GraphQL, REST) and then a fine-grained authorization system on it. Like Nikolas said, very different from Prisma. Hasura aims to add value as “infrastructure” by guaranteeing performance and security where as Prisma is like an ORM/database toolkit.

hbrundage 6y ago

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 https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/query-engine/ 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 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 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.

Sytten 6y ago
A few things to note: - Prisma 1 was a completely independent server and Prisma 2 was most likely started as a rewrite of Prisma 1 so it followed the same approach - This indirection will be removed if someone can finally land a Rust binding to NAPI (looking at you Neon binding people) - Prisma plans to support multiple languages thus it makes sense to have an agnostic engine - This not far from having a PG engine coded in C and interfacing with like like most libraries do anyway, javascript is just too slow for this kind of stuff

davedx 6y ago

Does it have migrations yet? 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.

gabrielizaias 6y ago
They have, but it's "experimental" at the moment: https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-migrate https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
nikolasburk 6y ago
Today's release unfortunately doesn't include our migration solution Prisma Migrate [1] yet. We totally understand that a lot of people want to get "database access" and "schema migrations" with the same tool/library, that's why we're focusing most of our engineering efforts on Prisma Migrate next and will hopefully be able to release that soon! However, we do see a lot of folks using third-party migrations (like knex.js or indeed Sequelize) and then still get the benefits of Prisma Client [2] through introspection [3] for the time being. For non-critical applications we also already see lots of users who are trying out Migrate and help us improve it through constant feedback! I'd love to hear your thoughts on the current version so that we can make sure to consider your feedback and ideas for Migrate when building it out over the next few months. [1] https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-migrate https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [2] https://www.prisma.io/blog/announcing-prisma-2-n0v98rzc8br1/#how-prisma-client-boosts-productivity-and-raises-confidence https://www.prisma.io/blog/announcing-prisma-2-n0v98rzc8br1/... [3] https://www.prisma.io/docs/reference/tools-and-interfaces/introspection https://www.prisma.io/docs/reference/tools-and-interfaces/in...
- andrewingram 6y ago
  Is there a plan for a higher-level migration API rather than just generating + executing raw sql strings?

wiremine 6y ago

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?

nikolasburk 6y ago
I think one very common characteristic of most ORMs is that tables are defined in terms of classes (often called models). You then instantiate these classes to work with the model instances for data storage and retrieval. Prisma takes a fundamentally different approach by generating a database client that returns plain old JS objects. We've written more extensively about this topic in the docs: https://www.prisma.io/docs/understand-prisma/why-prisma https://www.prisma.io/docs/understand-prisma/why-prisma
2color 6y ago
Daniel from the Prisma team here. Both Prisma and ORMs abstract away from SQL and let you "think in objects". However, how they do that is different. With ORMs, you typically map tables to model classes With Prisma, the focus is on queries and structural typing; queries return plain objects that are fully typed based on the query. For a broader comparison with ORMs, check out the documentation page about why Prisma is not an ORM: https://www.prisma.io/docs/understand-prisma/prisma-in-your-stack/is-prisma-an-orm https://www.prisma.io/docs/understand-prisma/prisma-in-your-...
- wiremine 6y ago
  Cool, thank you very much!

hn_reddit_human 6y ago

If I understand correctly, transactions are currently not supported for doing any advanced business logic beyond building CRUD: https://www.prisma.io/docs/reference/tools-and-interfaces/prisma-client/transactions#future-transaction-support-in-prisma-client https://www.prisma.io/docs/reference/tools-and-interfaces/pr... Also, no mention of aggregations, or if someone could point me to it? 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. Any comments from HN folks about why that is?

ssijak 6y ago
People are scared of SQL or they want to use their objects for data access, business logic and views at the same time (leading to bad architecture and headaches), or they come from Nosql world, or they want a shiny new tool, or they do not understand features of their used db well, or because “everybody is using ORM zyz”... Just from the top of my head, there are probably more.
doug78 6y ago
How can ORM be used with Prisma?

rodolphoarruda 6y ago

"The problem: Working with databases is difficult" 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?"

nikolasburk 6y ago
Scarily close to reality :D
- sorenbs 6y ago
  :-P

mesaframe 6y ago

It's funny how suddenly everyone is moving towards types. A couple of years back which was frowned upon. And was seen as anti productive.

ctrlplusb 6y ago
True. A big appeal for me with TS is that the inference engine is decent, so doesn't feel too ceremonious, and I can also tap out of the type system at any point and write a bit more gnarly code. Typing just the boundaries can be super helpful sometimes.
marcosdumay 6y ago
If by "a couple" you mean 10 to 15, then yes, that's correct. Look at the modern type systems we have around and try to see how they are different from what was mainstream by that time.
- mesaframe 6y ago
  I am not talking about the state of type system. But, how they were projected as one. Especially when dynamic languages were getting popular.
deleted 6y ago
[deleted]

jhanschoo 6y ago

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: https://github.com/prisma/prisma-client-js/issues/153 https://github.com/prisma/prisma-client-js/issues/153 ), and there seems to be interest in improving it. 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.

flybayer 6y ago

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. It certainly doesn't replace the need to know some SQL, but it does delay that which is great for so many people. I'm definitely using this instead of any ORM for every project I can. I really love having the fully typed interface for Typescript. Both for static type checking and for code completion in your editor. 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. [1] https://blitzjs.com https://blitzjs.com

narrationbox 6y ago
What are your thoughts on RedwoodJS? https://github.com/redwoodjs/redwood https://github.com/redwoodjs/redwood
- flybayer 6y ago
  Great alternative if you don't care about Next.js and you absolutely want to use GraphQL.

visopsys 6y ago

Any to solve the SQL long string problem? I hate having to write another custom SQL migration script beside Prisma migration script. For your reference: https://github.com/prisma/prisma/discussions/2138 https://github.com/prisma/prisma/discussions/2138

andy_ppp 6y ago

The magic is great! Until it stops working in production...

TLadd 6y ago

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. 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. Couple of other things I've run into that already have github issues: - It would be great if along with the create/connect options on relationships for nested writes there was also an upsert. - 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.

nikolasburk 6y ago
Thanks so much for sharing your experiences with Prisma! > 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. Better re-introspection flows are indeed very much on our radar and something that we want to tackle soon! Would be great if you could leave a comment with your use case on GitHub [1], so we can make sure to address it properly when planning and prioritizing new features! :) > Better transaction support beyond just nested writes would be great and probably a requirement for a lot of apps. Same here! It would be really helpful for us if you could share some details about your use cases for transactions in the feature request [2] so that we can incorporate them in our planning and design of the feature! [1] https://github.com/prisma/prisma/issues/2425 https://github.com/prisma/prisma/issues/2425 [2] https://github.com/prisma/prisma/issues/1844 https://github.com/prisma/prisma/issues/1844

enahs-sf 6y ago

Not sure I 100% agree with their problem statement. > the problem: Working with databases is difficult 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.

ronanyeah 6y ago
Well said. Though Hasura makes it easier.
arxpoetica 6y ago
Agree to disagree. For certain kinds of programmers who tend to think more analytically, databases are easy to work with. For those of us who tend to think more visually or kinesthetically, I appreciate tools that are trying to solve problems at a less-lingual/code level.
- albertgao 6y ago
  Isn't a DB naturally embrace 'visually'? I mean, there is a table. Every time I think of a table, I get a picture in my brain... xD
ogre_codes 6y ago
> A more accurate statement would be: choosing the right access method to work with databases is difficult. For me, it's the fiddly bit where you interface between the programming language and the database is a PITA.
- nikolasburk 6y ago
  This is exactly how it's meant in the article btw!

nikolasburk 6y ago

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 and a GraphQL API with a PostgreSQL database. You can find the full recording here: https://www.youtube.com/watch?v=AnJxKWQG_fM https://www.youtube.com/watch?v=AnJxKWQG_fM

gsvclass 6y ago

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. https://github.com/dosco/super-graph https://github.com/dosco/super-graph

gsvclass 6y ago
Use it to replace your ORM in your own GO app. No more having to struggle with joins etc just describe the data in GraphQL and Super Graph will generate the SQL for you.
nikolasburk 6y ago
Just as a side-note, with Prisma we're planning to support more languages beyond the Node.js/TypeScript ecosystem. We're currently already working on a version of Prisma Client in Golang, you can see the first prototype and track the development on GitHub: https://github.com/prisma/prisma-client-go https://github.com/prisma/prisma-client-go
newusertoday 6y ago
this looks great do you know if anyone is using it in production?
- gsvclass 6y ago
  Yup a few startups mostly using the standalone version. One even runs it alongside their Rails app on Google Cloud Run to add a high-performance graphql api to an existing Rails app. I'm speaking to a couple people who want to use it within their traditional GO REST API to query the database instead of using an ORM.

dang 6y ago

A thread on this from a couple months ago: https://news.ycombinator.com/item?id=22739121 https://news.ycombinator.com/item?id=22739121

benatkin 6y ago

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. https://github.com/redwoodjs/redwood https://github.com/redwoodjs/redwood https://github.com/blitz-js/blitz https://github.com/blitz-js/blitz As a status announcement, this isn't quite as exciting as it sounds because migrations are still "experimental". Still great to see!

olso 6y ago

So with Prisma 2.0 I could replace https://www.npmjs.com/package/schemats https://www.npmjs.com/package/schemats + https://sqorn.org/ https://sqorn.org/ ?

nahtnam 6y ago

Been using Prisma for a while. Nothing better than typing `await prisma.`, hitting ctrl+space, and having it autofill everything for you! :)

ogre_codes 6y ago

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. So, bring on type safe access, but don't make me learn yet another DSL which only works 70% of the time.

albertgao 6y ago
the DSL is only for table management, and pretty similar to GraphQL type definition The ORM layer is not a DSL but some nicely done JS/TS functions
- ogre_codes 6y ago
  > The ORM layer is not a DSL but some nicely done JS/TS functions You are splitting hairs here as far as I'm concerned. You need to learn the an API so you can do 70% of your queries. Then you need to learn SQL so you can do the other 30% of your queries and actually understand how to design a database. The queries that the "nicely done JS/TS functions" are replacing are almost always the simplest, most basic queries. Do you really need a special query language to say `select * from widgets`? The big problem with every ORM layer is you are essentially learning a disposable language. Every ORM says it's the best way to Query ever, and yet here we are, 5000 ORMs later and SQL is still an essential skill for developers. I know... "This time it's different!".

OJFord 6y ago

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.