17 ms·

Prisma – ORM for Node.js and TypeScript

424 points by Sujan 5y ago

abaldwin99 5y ago
I'm completely perplexed at some of the functionality that's absent in Prisma? I'm coming from the Rails/Django world for reference. Can anyone help me understand if I'm out in left field or does this technology only cover basic use cases? - No supported way to do a case-insensitive sorting. https://github.com/prisma/prisma/issues/5068 - Can’t sort by an aggregate value like user’s post count. https://github.com/prisma/prisma/issues/3821 - Can’t control between inner/left join. - Can’t do subqueries. - Migration rollbacks are experimental maybe unsupported now? At least I only see mention in Github issues and not in the docs. - Transactions appear to expect a series of queries? It doesn’t look like you can execute any app code during a transaction? - No support for pessimistic row locking e.g. SELECT… FOR UPDATE ? - No way to mixin raw query partials like `where('name ILIKE ?')`. You either need to write the whole query raw or not. - Validations are done at the database level. - Complex validations seem tricky to write in this format - No built-in way to make clean user-facing validation messages. - You can’t check that a model instance is valid without just trying to insert it into the database - The official documented validation example has you connecting via psql and adding a constraint? - So following the offical example my validations aren’t documented in the codebase via a model or a migration? - Also they don’t have a validation example documented if you’re using MySQL instead of Postgres? - Cascading deletes are handled the same way as validations. As in Prisma basically does nothing other than document how to implement it yourself outside of the library. - No model methods. I guess that's not a surprised because it's "not an ORM". A model really is just a data mapping? Anyways it seems like you would end up rolling your own wrapper around this and there's no recommendations on standardized architecture. - No callbacks. These have been controversial at times so are teams using Prisma writing something akin to "services" instead? - Syntax nitpick but one of these is vulnerable to a SQL injection and it seems really easy for a new developer to get mixed up? - prisma.$queryRaw(`SELECT \* FROM User WHERE email = ${email}`); - prisma.$queryRaw`SELECT \* FROM User WHERE email = ${email}`; - No way of batch loading like Active Records’s find_in_batches / find_each. All objects are just loaded into memory? - No way of hooking into queries for instrumentation. e.g. ActiveSupport::Notifications.subscribe FYI - This is after fairly brief research. Not guaranteed 100% accurate.
- abaldwin99 5y ago
  @nikolasburk can you comment? Before compiling this list I was seriously considering using Prisma to kick off a big upcoming project. In the spirit of being open-minded I'd really like to know if I'm fundamentally misunderstanding Prisma capabilities.
  - nikolasburk 5y ago
    This is a pretty extensive list! Are all of these points are full blockers for you or are there individual points that you care more about while others might be rather "nice to have"? If most of them are real blockers, you probably shouldn't use Prisma [1], and that's ok :) Prisma certainly is not perfect and whether you should use it depends on your project and individual requirements. What I can tell you is that we are shipping releases [2] with new features and improvements every two weeks. We are also very eager to learn about more use cases that people want to accomplish with Prisma. The best way to bring these to our attention is by commenting on existing GitHub issues and creating new ones if the one for your use case doesn't exist yet. This helps us prioritze and implement these new features. We also have a roadmap [3] where you can see all the features that we are currently working on. Hope that helps for now! [1] https://www.prisma.io/docs/concepts/overview/should-you-use-prisma https://www.prisma.io/docs/concepts/overview/should-you-use-... [2] https://github.com/prisma/prisma/releases https://github.com/prisma/prisma/releases [3] http://pris.ly/roadmap http://pris.ly/roadmap
    - abaldwin99 5y ago
      Thanks for getting back to me! Most of these are pretty important to us. I did try to put lower priority items near the bottom of the list. However, I did omit several nice-to-haves already. e.g. ActiveRecord's ability to diff changes after an update (ActiveModel::Dirty) I wouldn't say any of them are complete full blockers by themselves but cumulatively yes they prevent us from considering Prisma for most projects.
- tomhoule 5y ago
  I can clarify one point, relative to migration rollbacks. We indeed chose not to implement down migrations as they are in most other migration tools. Down migrations are useful in two scenarios: in development, when you are iterating on a migration or switching branches, and when deploying, when something goes wrong. - In development, we think we already have a better solution. Migrate will tell you when there is a discrepancy between your migrations and the actual schema of your dev database, and offer to resolve it for you. - In production, currently, we will diagnose the problem for you. But indeed, rollbacks are manual: you use `migrate resolve` to mark the migration as rolled back or forward, but the action of rolling back is manual. So I would say it _is_ supported, not just as convenient and automated as the rest of the workflows. Down migrations are somewhat rare in real production scenarios, and we are looking into better ways to help users recover from failed migrations.
ponyous 5y ago
I'm just about to start working on DB layer for our app with TypeScript. Any other alternatives to prisma you guys prefer and why?
- eydwales 5y ago
  I suggest to not add a layer. Stay close of the SQL request, you can simply have a function that will fulfill an access pattern. No need for ORM.
  - ponyous 5y ago
    Yeah, I have no problem with minimum ORM (prepared statements type of thing) - That's why I am asking the question, Prisma seems a bit too much. Usually I just use simple ORM helpers (get by primary key for example) and anything complex is raw sql. What I am looking for is ideally something that helps with type saftey and seeds/migrations/schema creation.
    - topicseed 5y ago
      Try Knex!
    - domlebo70 5y ago
      https://github.com/gajus/slonik https://github.com/gajus/slonik
    - heisenbit 5y ago
      I'm wondering at the moment whether Knex (solid query builder and migration) and Objection.js would not do this trick. That combo seems to give me json validation which is nice and seemingly both a way to handle entities and graphs in an efficient way.
    - gmac 5y ago
      https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/ (no built-in migration support, though)
    - 5y ago
loloquwowndueo 5y ago
“ Application developers should care about data – not SQL” Anyone who has been bitten by an ORM generating inefficient SQL (and subsequent having to learn and care about SQL) knows the above not to be true.
- whatl3y 5y ago
  While some people are hard lined enough on their anti-ORM stance that it sort of becomes weird, I agree with you that my beef with ORMs comes from being burned before a couple of times by a super inefficient aggregation ActiveRecord did on GROUP BY queries that it 1. not only took a really long time to figure out why a particular page in our app was loading slow but 2. we ended up having to write raw SQL to fix it. I think the answer of whether to use one depends on the type and load/volume of app you're working with combined with the dynamics, size, and skill level of your team(s). I'm extremely comfortable writing, profiling, query planning, and debugging SQL queries. Others aren't, and therefore having an ORM to query data in the DB with the syntax of the language you're using in your projects makes way more sense, if nothing other in order to speed your team up.
  - cknoxrun 5y ago
    Not sure when you used ActiveRecord, but slow query logging helps a lot to identify these issues. I also appreciate that in the docs for ActiveRecord they make it very clear that jumping to raw SQL is absolutely fine and normal, and they make the interface for doing that very nice.
- nikolasburk 5y ago
  This statement is certainly provocative (great that it was the first thing picked up here :D) but I'm happy to explain our rationale for this a bit more. SQL is an impressive technology and has stood the test of time! Yet, we claim that it's not the best tool for application developers who are paid to implement value-adding features for their organizations. SQL is complex, it's easy to shoot yourself in the foot with and its data model (relational data / tables) is far away from the one application developers have (nested data / objects) when working in JS/TS. Mapping relational data to objects incurs a mental as well as a practical cost! This is why we believe that in the majority of cases (which for most apps are fairly straightforward CRUD operations) developers shouldn't pay that cost. They should have an API that feels natural and makes them productive. That being said, for the 5% of queries that need certain optimizations, Prisma allows you to drop down to raw SQL and make sure your desired SQL statements are sent to the DB. I see Prisma somewhat analogous to GraphQL on the frontend, where a similar claim could be: "Frontend developers should care about data, not REST endpoints". GraphQL liberates frontend developers from thinking about where to get their data from and how to assemble it into the structures they need. Prisma does the same by giving application developers a familiar and intuitive API.
deepstack 5y ago
Hmm, how does this compare to sequelize? Seems like the only reason to use prisma is the GraphQL integration. If anyone has used both please share. I've being mainly using sequelize and have being quite happy with it.
- nikolasburk 5y ago
  Hey, Nikolas from Prisma here! Can you elaborate what exactly you mean with "GraphQL integration"? You might be referring to Prisma 1 which was a "GraphQL layer for your database". Prisma 2 (which we are referring to with this article) doesn't have a native GraphQL integration any more :) Prisma is very different from Sequelize in various ways (see our docs [1]): - Your data model lives in the Prisma schema - Database access doesn't happen via model instances but via the Prisma Client API [2] which always returns plain JS objects making your queries much easier to reason about - Prisma Migrate auto-generates migrations based on your data model (and lets you customize these migrations when needed) - Prisma comes with Prisma Studio out of the box – a modern database GUI - Prisma is not a community-project but built by a VC-funded company – We care a lot about our community, documentation, and providing support (something we've seen lots of developers complain about with other ORMs) [1] https://www.prisma.io/docs/concepts/more/comparisons/prisma-and-sequelize https://www.prisma.io/docs/concepts/more/comparisons/prisma-... [2] https://www.prisma.io/client https://www.prisma.io/client
  - deepstack 5y ago
    >Prisma is not a community-project but built by a VC-funded company Thanks for clarifying this. I know there tend to be a kneejerk reaction towards VC-funded software projects. How do you guys plan to make money on this?
    - nikolasburk 5y ago
      We've explained this in the blog post here: https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjeawmb#open-source-and-beyond https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjea... I think this quote summarizes our plans nicely: Prisma's vision is to democratize the custom data access layer used by companies like Facebook, Twitter and Airbnb and make it available to development teams and organizations of all sizes. The open-source ORM we're launching today will of course remain open-source and we'll keep investing into it since it's be the foundation for the commercial tools that folks will be able to use on top.
SlackingOff123 5y ago
I don't have much experience with node.js, so this question might sound silly. I don't see anything about database support in the blog post. Is Prisma enough to work with a PostgreSQL database from node.js? If not, what else am I missing?
- atraac 5y ago
  Prisma does support Postgres. https://www.prisma.io/docs/reference/database-reference/supported-databases https://www.prisma.io/docs/reference/database-reference/supp...
- deleted 5y ago
  [deleted]
- Sujan 5y ago
  Easy to miss in the long blog post: > Prisma currently supports PostgreSQL, MySQL, SQLite, SQL Server (Preview). A connector for MongoDB is in the works, sign up for the Early Access program here (https://prisma103696.typeform.com/to/FriDuIeM https://prisma103696.typeform.com/to/FriDuIeM).
brap 5y ago
I’ve been using Prisma for a while and I quite like it. Best ORM for TypeScript I’ve used. My biggest issue with it is testability. Sure, I can mock the Prisma client in tests with Jest or something, but if I want to test state I pretty much have to reimplement an in-memory DB using JS mocks. I can also connect to a real DB made for testing but it’s quite overkill, I’m usually not interested in testing Prisma itself, just my own code. I wish Prisma had test mode, where you could replace the client with a temporary in-memory SQLite DB without writing tons of boilerplate. A drop-in replacement for PrismaClient for tests would have been wonderful.
- high_density 5y ago
  using tmpfs... it'll help a bit (I used mysql-on-tmpfs before)
- vbsteven 5y ago
  Could you elaborate on why you find a real DB overkill for testing purposes? Typically you would have a set of unit tests which test your code only and use mocks for external dependencies, in this case you would mock Prisma. Tests involving DB state are not unit tests anymore and require a bit more setup but most frameworks provide a test harness/runner to quickly spin up a part of your app with dependencies resolved (instead of mocked) so you can call controller/handler/service methods directly and verify their behavior. The boilerplate for this should mostly be limited to switching out an environment variable for the database connection and maybe setup some fixtures. Is this not possible in Prisma?
- ragnese 5y ago
  Isn't that pretty much always the dilemma with database stuff and testing? On the one hand, you can wrap your DB operations in some kind of mockable interface(s), and then test your business logic. On the other hand, you really need to test that the actual SQL ops work anyway- what if you screwed up a foreign key constraint?- that wouldn't show up in your business logic tests or your in-memory SQLite or whatever.
- matthewmueller 5y ago
  Thanks for this feedback. We're very aware of this problem and are are actually working on a guide for working with Jest right now. It's a tricky problem because our use of the type-system is quite complex. I quite like your idea of a test mode or maybe a mock client that we generate.
dickfickling 5y ago
I LOVE Prisma. I’ve used Django, SQLAlchemy, Sequelize, Knex, and TypeORM in the past. all had rough edges that continually frustrated me or didn’t provide the functionality i needed. Prisma is different. It’s absolutely got rough edges, but the extremely strong type safety makes Sequelize look like a joke. The query engine itself, written in rust, combines and optimizes queries inside every tick of the event loop so GraphQL N+1 issues are a thing of the past. Also, the team and community behind it are amazing! I never thought having an active dev community behind an ORM would be important, but as the author of Sequelize-Typescript was forced to abandon it late last year and the author of TypeORM was also pretty much absent, Prisma was a breath of fresh air. I REALLY hope they can find a way to build a sustainable business out of it. Support packages, feature development contracts, something to keep them financially incentivized to keep making it better. Happy to answer any questions about my experience using it if anyone has any.
- brap 5y ago
  > GraphQL N+1 issues are a thing of the past. Huh, care to explain this one? I’m using Prisma with Apollo Server without doing anything fancy in my resolvers. I just assumed I’m getting N+1 issues but didn’t bother to optimize yet.
  - dickfickling 5y ago
    in short the separate engine process allows them to combine every findX call you make during one tick of the event loop into a single SQL query, following the dataloader pattern, so you don’t have to implement it yourself. i’m sure @nikolasburk can shed some more light if you’re interested.
    - eurasiantiger 5y ago
      I have a feeling that does not work at all in non-trivial scenarios, e.g. if both composite keys and date range matching are required to resolve a reference.
      - 5y ago
Zealotux 5y ago
How is Prisma's support (if any) of Mongo? I use it in combination of Postgres for prototyping and I'm wondering if they play well together.
- codethief 5y ago
  See https://news.ycombinator.com/item?id=26888427 https://news.ycombinator.com/item?id=26888427
CGamesPlay 5y ago
I have adopted Prisma in my latest project and I have mixed feelings about it. - The generated client is top-tier. Fully specified in TypeScript with intelligent types that can be extended by the user. - The schema language is great. It provides a cohesive experience that can fully express your database structure, and it also provides a migration framework to manage that structure's evolution. - There's no hook for implementing access control at the model level, so you end up needing to create a higher-level API around the base queries to implement these yourself, which is a fairly large investment. I'd love to see a pair of functions that can modify the query before it gets sent to the Prisma engine to add extra query values, and a second function that can filter models before they are returned to the caller. Where Prisma falls short is in testing. The testing story in Prisma is that you can either use a live database, or you can completely stub out all calls to Prisma in your application. The latter means you end up writing a bunch of tests for implementation rather than for behavior, or you end up manually writing an in-memory database that fits the Prisma API. The former means that you need to completely recreate your database after every test case. The discussions on the Github seem to indicate that the old "wrap the test in a transaction" trick is forbidden, and Prisma seems architecturally set up to ensure that you can't even hack this behavior in. All in all, we probably won't switch away from it, but I will continue to look for a better way to test my endpoints.
- agustif 5y ago
  Hey totally off-topic maybe as it's not prisma-related/required. What do you think of using something like msw.io for mocking your endpoints as needed?
  - tor291674 5y ago
    > msw.io The website is https://mswjs.io/ https://mswjs.io/
- kami8845 5y ago
  While depending on a live DB for testing isn't great, why not just blow away database state after every test by running TRUNCATE / DELETE against all tables? DELETE especially is very fast (couple ms) if you're not inserting large amounts of data during your test runs.
RivieraKid 5y ago
How does it compare to MikroORM? I was researching different ORM options and almost wanted to give up until I discovered MikroORM, which is simply great. Edit: After quickly going through the intro, I prefer MikroORM, it's simpler.
- deleted 5y ago
  [deleted]
- cjpb 5y ago
  I've tried Prisma, TypeORM and MikroORM and I'm certainly the most impressed with MikroORM. It's simple and the use of identity map within a unit of work, tied to a request context (for example), is just brilliant. The handling of relations (with configurable loading strategies) and other features such as Embeddables and Filters make it a real joy to use. And if at any point I can't achieve something with MikroORM itself (which generally in my case is calling a PostgreSQL function), I can easily grab the underlying Query Builder from Knex. It also has the tooling to generate a schema from your Entities, or generate Entities from an existing schema - so it's easy to get started on something new or existing.
seer 5y ago
I know prism adds soo much more than just data access for your project, but for just replacing ORMs I think I really prefer the approach of https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped where you have raw sql files / template literals and it will create types for parameters and results.
- nickreese 5y ago
  Pgtyped made sql+typescript a pleasure.
daralthus 5y ago
Can someone compare to Hasura please? What has been your experience?
- terrortrain 5y ago
  I came here with the same question. Hasura is really awesome, so far as I have used it. Now I gotta look into prisma I almost wonder if they aren't mutually exclusive. With hasura, you need to run your own server anyways, for auth or special cases. Maybe that server could run prisma? Let hasura do the migrations, and prisma track it?
- nwienert 5y ago
  I use Hasura and generally like it, it certainly has some sharp edges, but overall has worked. I think Hasura has much richer GraphQL support, which I pair with gqless[0] to get what I think is a much nicer client side / ORM experience overall. Other upsides are a much better RBAC column/row permissions, migrations with up/down, a better admin UI. [0] https://gqless.com https://gqless.com
  - sbacic 5y ago
    What sharp edges are you referring to? I find that with new tech, I'm more interested in what it can't do rather than what it can.
    - nwienert 5y ago
      Hard to remember them all now, but definitely had a number of bugs I've ran into, most able to be worked around. For example a recent one was a huge slowdown in a simple query that should be optimized[0], still have no great solution for it or attached to any roadmap. One big one is at some point you need caching on a query level, and for that you have to purchase enterprise. I suppose they need to make money somehow, and it's a smart level to do it because it's almost impossible to not need caching at some fairly early stage. It would be nice if they let you test it out without "Contact Sales", and while there may be some way to wrap it from above, I don't think it's very easy. A meta critique would be the project seems to have less momentum than Prisma. Releases aren't as frequent or large, and I'd have much preferred they double down on PG and keep adding query abilities, performance, etc, instead of expanding database engines. [0] https://github.com/hasura/graphql-engine/issues/5745 https://github.com/hasura/graphql-engine/issues/5745
nickreese 5y ago
For those of you that want typed SQL queries check out pgtyped[1]. Using it in production and it is great for writing arbitrary SQL queries and getting full typescript support. [1] https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped
- nikolasburk 5y ago
  pgtyped is awesome! We mention it along with similar tools like Slonik and Zapatos in our docs here: https://www.prisma.io/docs/concepts/overview/should-you-use-prisma#-you-want-to-use-raw-type-safe-sql-for-querying-your-database https://www.prisma.io/docs/concepts/overview/should-you-use-...
agustif 5y ago
Oh also, Blitz.js is a nextjs fullstack framework that uses and autogenerates prisma code to work with. Also FoalTS is a nice small framework for building rest endpoints with TypeScript, and recently landed @prisma support/documentation besides typeorm. Just random fyi, hope someone finds it useful if they wan't to try prisma in a more batteries included package.
yewenjie 5y ago
I am a noob in these matters which one is advised if one is to start a GraphQL API from the beginning - use DBs that directly provide GraphQL endpoints such as Fauna, Upstash, etc. - use an ORM with more traditional DBs. What are the pros and cons of each?
- elitan 5y ago
  I prefer having the database as a single source of truth and use something like [Hasura](https://nhost.io https://nhost.io) to generate the GraphQL API.
  - ic4l 5y ago
    I second this, Hasura is a solid choice.
  - ridicter 5y ago
    I tried out nhost a few weeks ago and it was great!
- databrecht 5y ago
  There is value in both, at Fauna we provide GraphQL out the box. Using Fauna directly would eliminate an indirection and is probably slightly more efficient. However, if there is a GraphQL layer like Prisma in between you could essentially change to any database with less impact on your application. This is tremendously interesting for people who develop frameworks, using prisma gives them the advantage of supporting multiple databases immediately. Or for application developers it could allow you to move from a non-scalable database to a scalable database once it becomes necessary or simply just switch databases if the database maintenance is causing you grief. I'm for one looking forward to Prisma supporting Fauna since if the interface is the same, there are even less reasons not to choose a scalable managed database instead of managing your own db :). And I would say that Prismas interface is quite great! Note: the performance impact does depend heavily on whether your database maps well on ORMs. Traditional databases have an impedance missmatch when it comes to translating tables to an objet format. Graph databases or the way Fauna works (documents with relations and map/reduce-like joins) map well on ORMs so the performance impact would be small.
ARussell 5y ago
I'm sure a lot of hard work went into this, so I mean no offense here when I give my honest feelings. The big differences between v1 and v2 make me uneasy. I am reminded of the constant API churn of React-Router, or the complete change from AngularJS to Angular. This approach makes me very hesitant to learn the library, because I am afraid of having the choice of painful upgrade or a dead dependency down the road. I am also wary of the library being VC-funded, because I am afraid of what kinds of features will be held at ransom down the line once they need to start making money.
gmac 5y ago
I've found this a very helpful summary of TypeScript SQL libraries: https://phiresky.github.io/blog/2020/sql-libs-for-typescript/ https://phiresky.github.io/blog/2020/sql-libs-for-typescript...
heroic 5y ago
We tried converting from Sequelize to Prisma and learned transactions were not fully supported... Can't build an app without transactions
- arcturus17 5y ago
  Is this for real? And what are people building that wouldn't need this?
  - nikolasburk 5y ago
    Transactions are supported in Prisma, see this guide in our docs [1]. I guess the post refers to our opinionated stance on "long-running transactions" which Prisma indeed does not at the moment. The best resources to learn about this are on GitHub [2] and our blog [3]. [1] https://www.prisma.io/docs/guides/performance-and-optimization/prisma-client-transactions-guide https://www.prisma.io/docs/guides/performance-and-optimizati... [2] https://github.com/prisma/prisma/issues/1844 https://github.com/prisma/prisma/issues/1844 [3] https://www.prisma.io/blog/how-prisma-supports-transactions-x45s1d5l0ww1 https://www.prisma.io/blog/how-prisma-supports-transactions-...
steipete 5y ago
How are they going to make money?
- nikolasburk 5y ago
  We've explained this in the blog post here: https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjeawmb#open-source-and-beyond https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjea... I think this quote summarizes our plans nicely: Prisma's vision is to democratize the custom data access layer used by companies like Facebook, Twitter and Airbnb and make it available to development teams and organizations of all sizes. The open-source ORM we're launching today will of course remain open-source and we'll keep investing into it since it's be the foundation for the commercial tools that folks will be able to use on top.
  - goliatone 5y ago
    How does “democratize the custom data access layer” make money?
    - vptr 5y ago
      I have no idea what this means either. Sounds like a bunch of buzzwords about nothing.
      - nikolasburk 5y ago
        It means that Prisma will provide a data access layer (we call it "application data platform" [1]) similar to the custom data access layers built by big companies [2] (e.g. TAO by Facebook or Strato by Twitter) that enables application developers to better access their databases. We've explained that in the blog post here in the "Open-source, and beyond"-section [3]. Does that help? :) [1] https://imgur.com/O1lwo0v.png https://imgur.com/O1lwo0v.png [2] https://imgur.com/Hb9VOWN.png https://imgur.com/Hb9VOWN.png [3] https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjeawmb#open-source-and-beyond https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjea...
vsskanth 5y ago
What's the most recommended .net equivalent
Coxa 5y ago
Have been experimenting with mammoth [1] for postgresql and am quite happy with how close it is to actual SQL. [1] https://github.com/Ff00ff/mammoth https://github.com/Ff00ff/mammoth
pistoriusp 5y ago
We've been using Prisma in RedwoodJS since the early days. It's a great ORM that they're constantly improving, I'm super excited for the future!
segmondy 5y ago
I'm not a fan of ORM, never been and never will be. https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch https://en.wikipedia.org/wiki/Object%E2%80%93relational_impe... But my gosh "Application developers should care about data – not SQL"
- spmurrayzzz 5y ago
  That line triggered me as well. I have built hundreds of applications on top of databases w/ sql and nosql, and from that experience— the notion that a single ORM abstraction somehow ameliorates the burden of caring about how your queries are written is alarming to me.
skrebbel 5y ago
IMO any discussion about Node/TypeScript data access tools deserves a reference to Zapatos, which sort of is the anti-Prisma. It has all the type safety with none of the ORM (and it's Postgres-specific, for better and worse). I think it's got one of the best designed APIs I've come across. https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/
- parhamn 5y ago
  > prioritis[ing] ease of switching to another database tomorrow over effective use of this database today, are a source of misery. hah. This looks cool, thanks for sharing!
- nikolasburk 5y ago
  Fully agree, Zapatos is super nice – and so are similar tools like pgtyped and Slonik. We actually mention all these in our docs here: https://www.prisma.io/docs/concepts/overview/should-you-use-prisma#-you-want-to-use-raw-type-safe-sql-for-querying-your-database https://www.prisma.io/docs/concepts/overview/should-you-use-... I think the main difference of these libraries compared to Prisma is the level of abstraction. If you want to work with SQL and you appreciate type-safety, then all of these tools will be fabulous options for you! If you want to work on a somewhat higher level of abstraction but still have full type-safety, Prisma will be more appropriate.
- smt88 5y ago
  PgTyped is similar, and it's superior to any other data access layer I've ever used. Ever.
  - jadbox 5y ago
    Have you compared PgTyped to Zapatos (I haven't yet).
    - smt88 5y ago
      Not yet, but I will at some point. I don't really have any pain points with pgTyped yet.
bwship 5y ago
What is the business model for them? It seems that an ORM in and of itself is not sustainable, especially one that is free.
- nikolasburk 5y ago
  https://news.ycombinator.com/item?id=26888735 https://news.ycombinator.com/item?id=26888735
htkien 5y ago
I am over ORMs. I am looking at the documentation for Prisma Client at the moment, and I just think to myself "yet another ORM I have to learn". I have learnt so many ORMs, it is just stupid. SQL is SQL. I wish I had spent all that time further developing my SQL skills rather than learning the latest ORMs API. For my latest large project, I just used SQL and I am happy. All I did was add some code to make sure the snake case was converted to camel case. Things like returning arrays of child relations can all be done in SQL these days with things like json_agg and json_build_object and so on. Half of my SQL on the other hand doesn't even map to an ORM. Where is the insert ... select ... where not exists ... These things aren't even possible in the ORM concept model.
- zackify 5y ago
  It took me all of 1 hour to learn how to use prisma. It’s not as hard as you make it seem. They have a vs code extension for editing the prisma schema. It’s not hard to see that you make fields “String” @unique, etc. Just make one model and that’s 80% of anything you ever need. Want to make a relation? Make a new model model Posts { users User[] } Hit save, it adds the required code to relate it to the User model. Run the generate command. Make a client instance. Create something: db.NameOfModel.create() And as you’re typing, typescript is auto completing it. There’s barely anything else to learn. And it’s a quick doc search away. Don’t hate on it because you love sql, it’s a great tool.
  - htkien 5y ago
    >It took me all of 1 hour to learn how to use prisma. That is not how this works at all. You don't know what you don't know until you need "how do I do this query in prisma". You then spend an hour trying to figure it out, and maybe it isn't possible, then on to the next thing. It takes more than an hour to learn SQL, so if it takes you an hour to learn Prisma, you are missing something.
    - joshmanders 5y ago
      Have you even looked at Prisma's docs? I would rather forget everything about Prisma the second I wake up in the morning and have to read their docs on how to do everything all over again, every single day, than try to understand what the heck is going on in SQL's docs.
zackify 5y ago
For years node had pretty bad libraries for interacting with databases. Prisma is the first time it all just makes sense. The code generation, auto migrating without any code, automatic crud resolvers with nexus, the list goes on. After using it, I don’t know how you can use any other language for backend. It would just take you much longer and require so much extra work. Nothing like prisma exists in other languages.
knodi 5y ago
I used Prisma with TypeScript for rapid prototyping. It did what it said and did it well. I would highly recommend giving this a try.
fuadnafiz98 5y ago
Is it a good suggestion to use prisma as a beginner other than using some low level query builders like knex.js?
nerdkid93 5y ago
Over a year ago, I was investigating using Prisma to be the ORM for a GraphQL API of a Postgres database. When doing a proof-of-concept, I discovered that under the hood @prisma/client was spinning up it's own GraphQL server that it would send requests to in order to generate SQL to send to postgres. This extra middleware layer between my frontend code and postgres generated some pretty poor performing queries that took 50% longer to complete than the queries generated by using Hasura as our whole GraphQL API. A quick glance at the @prisma/client code makes it seem like this pattern is still the case, since they have an "engine-core" package that downloads a binary server behind the scenes and runs it on a free port in the background.
- vptr 5y ago
  Yup, would not touch Prisma with a 10 foot pole
- camjohnson26 5y ago
  That extra layer gives them flexibility to combine queries and cache
- inshadows 5y ago
  > they have an "engine-core" package that downloads a binary server behind the scenes and runs it on a free port in the background O_____O
- thedavidprice 5y ago
  I'm on the RedwoodJS core team and can 100% confirm early performance issues. That's no longer been the case recently. I've seen bulk operations perform just fine and even data pipeline use cases. Now the issue is DB performance in a serverless infra, which needs extra set up and config to perform consistently and at scale.
codeulike 5y ago
New idiom - "Well that was a complete ORM" (sorry just a joke, ORMs do have their place and this looks useful. I'd think of Prisma as a lightweight ORM because it doesn't try to do "Business Rules" as they are known. But then, trying to do Business Rules will generally turn everything into a nightmare anyway so maybe lightweight ORM is the way to go)
- mst 5y ago
  Even as an ORM author this made me laugh. ORMs are useful. ORMs aren't always the right answer. ORMs that don't let you mix and match so you can bypass any given layer of abstraction as required annoy the pants off me ... usually even more than anti-ORM zealouts annoy the pants off me. So, yeah, joke appreciated :D
metta2uall 5y ago
Prisma looks quite good but what held me back is the out-of-process "engine" that handles all queries and talks to the DB. I would imagine all this inter-process communication adds a decent amount of overhead.
subsection1h 5y ago
My team experimented with Prisma, and we ended up deciding to continue using raw SQL. Each of us has 10-20 years of experience writing SQL for PostgreSQL, so it wasn't a surprise that we decided against using an ORM yet again. But Prisma is probably the best ORM for Node.js that we've tried. For anyone who uses PostgreSQL and is interested in Prisma, check out the following message, which has a section that includes a list of features that were deemed out-of-scope (e.g., bulk upserts): https://github.com/prisma/prisma/issues/4998#issuecomment-766742955 https://github.com/prisma/prisma/issues/4998#issuecomment-76...
vaughan 5y ago
I think its unfortunate that Prisma is only server-side due to its Rust-based native DB module. I think we can achieve a huge simplification in the industry if we develop a universal state-management solution that runs in the frontend and backend. Without a consistent model, we are forced to write so much additional code to manage caching, optimistic UI updates, and offline capabilities. Current RDBMS' are not ideal (most data is better represented as a graph), but because the relational model is so widely used in the backend, they are a good candidate for a universal data store on frontend and backend. And it is possible to represent graph-like structures in RDBMS' too, but it makes SQL querying very unfriendly. GraphQL is an ideal language for declaratively specifying what data you need for the UI layer. If you doubt this, play around with the [Github GraphQL API][1]. It's an incredible experience to be able to explore and pluck exactly what you need. SQL and REST don't come close to this experience. But GraphQL is essentially providing us a nicer way to write SQL compared to using JOINs, and to output it in a nested format for convenient rendering with nice typing. But it lacks a huge amount of flexibility. So we should keep GraphQL as our API, but we should implement it client-side against a data model similar to what we use in our cloud db: SQL, and then do real-time syncing or use it as the model for our server-cache. An added benefit is we don't have to worry anymore about what is local-state and what is server-persisted, or worry about choosing a good state management solution client-side. The necessary pieces to make this happen don't exist at the moment, but I would have liked to use Prisma as the DB API for in-browser SQLite in the beginning. I think there is then the opportunity to go full-stack and offer developers a client-side GraphQL library that talks to an in-browser SQL DB and to end the constant turnover in state-management libraries. I think every frontend developer is overwhelmed at this point by the proliferation of these libraries, and the simplicity they go seeking in things like "just use React.Context api", don't offer them what they will eventually need which is optimistic UI updates, offline modes, real-time collaboration, local-first experiences, etc. I think we are all still in search of the right state management solution and it would be cool if Prisma did it! [1]: https://docs.github.com/en/graphql/overview/explorer https://docs.github.com/en/graphql/overview/explorer
kofejnik 5y ago
Used it once, it is nice(-ish) for simple use cases, but unfortunately it doesn't support working with multiple postgres schemas, which is surprising given that many complex apps use them to namespace their DBs. It was a total showstopper for us and we're back to writing raw sql for now
thatwasunusual 5y ago
A few months ago I spent a week testing all of the available ORMs for JS/TS, and Prisma came out on top. That said, Prisma isn't exceptionally good in any way, it's just not as bad as the alternatives; Mikro-ORM, TypeORM, Sequelize etc.
kkarimi 5y ago
Prisma is singlehandedly making my work life easier and better every day, can’t fault it much at all. Really lovely experience and the public slack community is super helpful too!
hmsimha 5y ago
I have mixed feelings about Prisma. I do think it might be the best general-purpose ORM for relational databases in the Node landscape, and support for Typescript with autogenerated interfaces is amazing. But it seems to fall short in some ways as well (my experience with ORMs in the past is limited to ActiveRecord and Mongoose, both of which I haven't touched in years). I've only been using Prisma for ~2 months, for an internal application on which I'm the sole developer, and I'll keep using it. But given a new project and freedom to choose, there's a very good chance I'd go with another ORM depending on the use case. One of the things that is most perplexing to me is the inability to autogenerate a seed file from existing data, to reseed a new database. This would be incredibly helpful for testing and working with staging data. For example, we have a staging database and staging server, and want to be able to reseed the database with some data set, but don't want to write all the data inserts by hand. I'm sure there are many ways to avoid doing this (db-specific export/import, scripting the inserts in a loop over a collection of arrays of values which you've curated by hand, or in our case just copying the sqlite db file). Still, Prisma's story around seeding and data fixtures in general currently leaves a lot to be desired. There have also been many rough edges I've run into around shaping results (getting category names which have been applied to all blog posts by a given user, for example), and applying schema changes, but I'm not willing to rule out user error / inexperience for many of these
eloff 5y ago
I don't like ORMs, but Prisma is one of the better ones. It avoids a lot of shortcomings of popular ORMs. I hope they find a way to make it work as a company. I've been following them over the years from the beginning of their journey through various pivots. To use an ORM effectively you must learn both the API of the ORM and SQL. It does not absolve you from learning SQL, which I think was one of the unstated attractions to junior developers. Then you have to map between the API of the ORM and how it translates that to SQL under the hood. Then you have to understand how it handles caching and sessions and how that all works under the hood. This has been the source of so much complexity and so many bugs over the years that I no longer think the benefits are worth the cost. As always, there are exceptions and caveats, but I now believe it's better to use SQL directly than to use an ORM. In general there is too much complexity in all the layers of abstraction in software development these days, and I think the industry is strangely blind to the consequences of this. Complexity is death to software, and it should not be taken on lightly. The entire craft of a software engineer boils down to eliminating complexity and simplifying problems, the better you can do that, the more productive an engineer you will be.[1] [1] https://github.com/sqljoy/sqljoy/blob/master/docs/pages/orm.md https://github.com/sqljoy/sqljoy/blob/master/docs/pages/orm....
- nawgz 5y ago
  > I think the industry is strangely blind to the consequences of this Well, I think if you're not blind to those things to some degree, you're stuck forever in a best-practices search, which I feel like more often than not ends up implying you have to rewrite your stack. For example, I do most of my development thru Hasura now. It writes insanely performant SQL queries translated directly from GraphQL. As a data consumer, you only have to worry about the shape of the data you want, and none of the implementation details. There is one endpoint, and you pass it queries against the schema it exposes. Implementation details are abstracted heavily here, but in a "good" separation of concerns way. I will never hand-write SQL again. Why would I? My front-ends can load everything in my data model expressively and with type safety thanks to graphql-codegen. Now imagine you read this and realize you work in a completely different method and this answers some of your problems. You may start parallel development, but you certainly can't stop forward progress just to evaluate your stack. So I think the blinders are key to progressing in the short term despite the productivity losses you're taking in the long term, and then when you phrase it like this it is surely no surprise companies behave like that.
karmakaze 5y ago
I was reading through the 'where' cases to see how complex queries are composed. I couldn't find any examples. e.g. WHERE id IN (<subquery>) if I built up <subquery> using the ORM. The other uncommon thing I look for is eliminating N+1 not just based on a given query and related entities, but given a starting collection and loading their related entities and further related entities. Icing is if it can do all the above while making intermediate results asynchronously available as it works through it all.
wasd 5y ago
How's the support for window functions? One thing I like about ActiveRecord is it's lazily evaluated and you compose queries. You can do p = Post.where(published: true); if x; p.where(x: true). Is that supported? Checked here for window function support. https://www.prisma.io/docs/concepts/components/prisma-client/aggregation-grouping-summarizing https://www.prisma.io/docs/concepts/components/prisma-client...
beders 5y ago
From the web page: "Application developers should care about data – not SQL" That is fundamentally wrong - or at least - it is very limiting. Think very hard about adopting a framework that tries to shield you from SQL. Because at the end of the day, you will be looking at SELECTS and INSERTS in your logs because you are wondering why things are so slow or why your memory usage skyrockets. It looks like Prisma allows you to go to raw SQL if you must, yet you won't have a good time using some of PostgreSQL more advanced features. If your domain model is simple and will remain simple in the future, then - by all means - use a builder that creates queries from your domain model. Use a single-source-of-truth approach that is usable from the back-end and front-end. In other cases, where your domain model changes over time, be very careful when choosing an ORM but extra double careful in picking the right data store.
tobyhinloopen 5y ago
Meanwhile I just want to write my migrations in plain SQL. Why do we care so much about hiding SQL, it’s easy.
gsvclass 5y ago
GraphJin is very similar but in Go. Also you can either embed the whole service as a library or just the GraphQL to SQL compiler. Another advantage of GraphJin is that the you write the queries in pure GraphQL not a library specific API. https://github.com/dosco/graphjin https://github.com/dosco/graphjin
Tronno 5y ago
The only time I have had to query a database using JS/TS is in React Native + SQLite. However, as far as I can tell, Prisma has no support for this stack, so TypeORM remains the only practical choice here - rough edges and all. I would love to try Prisma otherwise.
dang 5y ago
Past related threads: Prisma Raises $12M Series A - https://news.ycombinator.com/item?id=23651605 https://news.ycombinator.com/item?id=23651605 - June 2020 (111 comments) Prisma 2.0 – Type-safe and auto-generated database client - https://news.ycombinator.com/item?id=23466834 https://news.ycombinator.com/item?id=23466834 - June 2020 (107 comments) Prisma 2.0 Beta: Type-safe Database Access - https://news.ycombinator.com/item?id=22739121 https://news.ycombinator.com/item?id=22739121 - March 2020 (122 comments) Comparing Database Types - https://news.ycombinator.com/item?id=21060866 https://news.ycombinator.com/item?id=21060866 - Sept 2019 (170 comments) Prisma – Database tools for modern application development - https://news.ycombinator.com/item?id=19598287 https://news.ycombinator.com/item?id=19598287 - April 2019 (83 comments) Show HN: Prisma – Turn Any Database into a GraphQL API - https://news.ycombinator.com/item?id=17076202 https://news.ycombinator.com/item?id=17076202 - May 2018 (16 comments) Prisma Cloud – A GraphQL Database Platform - https://news.ycombinator.com/item?id=16529450 https://news.ycombinator.com/item?id=16529450 - March 2018 (9 comments) Prisma – An open-source GraphQL API layer for your database - https://news.ycombinator.com/item?id=16160803 https://news.ycombinator.com/item?id=16160803 - Jan 2018 (34 comments) Prisma: Turn your database into a real time GraphQL API - https://news.ycombinator.com/item?id=16159874 https://news.ycombinator.com/item?id=16159874 - Jan 2018 (9 comments)
- nikolasburk 5y ago
  Nice, thank you for digging these up!
debug-desperado 5y ago
I'd still take Hibernate and Entity Framework over any of the Node ORMs I've seen, including Prisma. The former usually have the feature you need to generate the queries you want, but you just haven't read enough of the docs to understand how to do so. The latter straight up lack the functionality and lack sufficient docs.
oso2k 5y ago
Maybe it's too late to change the name. When Palo Alto Networks acquired Twistlock (Container Scanning/Security products) 2 years ago [0], they folded it in & renamed it to Prisma Cloud [1]. Food for thought if prisma.io team is watching. [0] https://www.paloaltonetworks.com/company/press/2019/palo-alto-networks-completes-acquisition-of-twistlock https://www.paloaltonetworks.com/company/press/2019/palo-alt... [1] https://blog.paloaltonetworks.com/2019/11/cloud-prisma-cloud-compute-edition/ https://blog.paloaltonetworks.com/2019/11/cloud-prisma-cloud...
kache_ 5y ago
orm bad
rafaelvasco 5y ago
I use Mikro-ORM not Prisma but I couldn't help but use an ORM in my project. Dealing with Mongodb schemas and queries directly, and modelling associations between entities, hiding certain fields on select, selectively populating joined @ManyToOne properties and all that DB stuff, was a nightmare to do by hand. Changed everything to ORM and all my problems were solved. Annotated entities, annotated properties, queries, joins, hidden fields, @OnCreate triggers etc, everything nicely handled for me. So yeah, I love ORMs. Have yet to find something nicer than .NET Entity Framework + LINQ though. That stuff is amazing.
benho 5y ago
I dont have much to add technically, I just want to show my gratitude, it has been very helpful for one of my projects.
_carl_2_2_m__ 5y ago
I've been hunting for the perfect solution to reduce the boilerplate in the "database-backend-frondent stack" for years and came to the conclusion: There is no shortcut. And we don't need one. For most non trivial applications - when I used an ORM or other abstractions over SQL - there came the point at which I needed to dive quite deep into the workings of the ORM. However, learning how your DB and SQL works is much better spend time than learning the complexities of an ORM. Equally important: The time saved upfront diminishes over the lifecycle of the project. Often (not always) figuring stuff out about the abstraction costs much more time and energy than writing the boilerplate. Typing out the boilerplate is boring, that's why we hate it so much. Figuring something new out? Time flies ... For my projects I've got a template for basic CRUD operations including a frontend store. Full control, easy to use and understand and only a couple of minutes to fill in the field names for a new database table or view.
thebrubaker 5y ago
ORMs can be a pain. Setting up SQL schemas and managing migrations is also slow and tedious. Prisma won me over when my friend integrated it while we were working on SpaceTraders.io - things have mostly been going well. Main issue was not getting the transaction support needed for read / compute / write locks. Solved our needs for today with Redis, but we came very close to regretting the Prisma choice. Other than that the DX is amazing and the tooling is great. I think there is a lot of promise and I'm excited as they develop more advanced DB escape hatches.

424 points by Sujan 5y ago

I'm completely perplexed at some of the functionality that's absent in Prisma? I'm coming from the Rails/Django world for reference. Can anyone help me understand if I'm out in left field or does this technology only cover basic use cases? - No supported way to do a case-insensitive sorting. https://github.com/prisma/prisma/issues/5068 - Can’t sort by an aggregate value like user’s post count. https://github.com/prisma/prisma/issues/3821 - Can’t control between inner/left join. - Can’t do subqueries. - Migration rollbacks are experimental maybe unsupported now? At least I only see mention in Github issues and not in the docs. - Transactions appear to expect a series of queries? It doesn’t look like you can execute any app code during a transaction? - No support for pessimistic row locking e.g. SELECT… FOR UPDATE ? - No way to mixin raw query partials like `where('name ILIKE ?')`. You either need to write the whole query raw or not. - Validations are done at the database level. - Complex validations seem tricky to write in this format - No built-in way to make clean user-facing validation messages. - You can’t check that a model instance is valid without just trying to insert it into the database - The official documented validation example has you connecting via psql and adding a constraint? - So following the offical example my validations aren’t documented in the codebase via a model or a migration? - Also they don’t have a validation example documented if you’re using MySQL instead of Postgres? - Cascading deletes are handled the same way as validations. As in Prisma basically does nothing other than document how to implement it yourself outside of the library. - No model methods. I guess that's not a surprised because it's "not an ORM". A model really is just a data mapping? Anyways it seems like you would end up rolling your own wrapper around this and there's no recommendations on standardized architecture. - No callbacks. These have been controversial at times so are teams using Prisma writing something akin to "services" instead? - Syntax nitpick but one of these is vulnerable to a SQL injection and it seems really easy for a new developer to get mixed up? - prisma.$queryRaw(`SELECT \* FROM User WHERE email = ${email}`); - prisma.$queryRaw`SELECT \* FROM User WHERE email = ${email}`; - No way of batch loading like Active Records’s find_in_batches / find_each. All objects are just loaded into memory? - No way of hooking into queries for instrumentation. e.g. ActiveSupport::Notifications.subscribe FYI - This is after fairly brief research. Not guaranteed 100% accurate.

abaldwin99 5y ago
@nikolasburk can you comment? Before compiling this list I was seriously considering using Prisma to kick off a big upcoming project. In the spirit of being open-minded I'd really like to know if I'm fundamentally misunderstanding Prisma capabilities.
- nikolasburk 5y ago
  This is a pretty extensive list! Are all of these points are full blockers for you or are there individual points that you care more about while others might be rather "nice to have"? If most of them are real blockers, you probably shouldn't use Prisma [1], and that's ok :) Prisma certainly is not perfect and whether you should use it depends on your project and individual requirements. What I can tell you is that we are shipping releases [2] with new features and improvements every two weeks. We are also very eager to learn about more use cases that people want to accomplish with Prisma. The best way to bring these to our attention is by commenting on existing GitHub issues and creating new ones if the one for your use case doesn't exist yet. This helps us prioritze and implement these new features. We also have a roadmap [3] where you can see all the features that we are currently working on. Hope that helps for now! [1] https://www.prisma.io/docs/concepts/overview/should-you-use-prisma https://www.prisma.io/docs/concepts/overview/should-you-use-... [2] https://github.com/prisma/prisma/releases https://github.com/prisma/prisma/releases [3] http://pris.ly/roadmap http://pris.ly/roadmap
  - abaldwin99 5y ago
    Thanks for getting back to me! Most of these are pretty important to us. I did try to put lower priority items near the bottom of the list. However, I did omit several nice-to-haves already. e.g. ActiveRecord's ability to diff changes after an update (ActiveModel::Dirty) I wouldn't say any of them are complete full blockers by themselves but cumulatively yes they prevent us from considering Prisma for most projects.
tomhoule 5y ago
I can clarify one point, relative to migration rollbacks. We indeed chose not to implement down migrations as they are in most other migration tools. Down migrations are useful in two scenarios: in development, when you are iterating on a migration or switching branches, and when deploying, when something goes wrong. - In development, we think we already have a better solution. Migrate will tell you when there is a discrepancy between your migrations and the actual schema of your dev database, and offer to resolve it for you. - In production, currently, we will diagnose the problem for you. But indeed, rollbacks are manual: you use `migrate resolve` to mark the migration as rolled back or forward, but the action of rolling back is manual. So I would say it _is_ supported, not just as convenient and automated as the rest of the workflows. Down migrations are somewhat rare in real production scenarios, and we are looking into better ways to help users recover from failed migrations.

ponyous 5y ago

I'm just about to start working on DB layer for our app with TypeScript. Any other alternatives to prisma you guys prefer and why?

eydwales 5y ago
I suggest to not add a layer. Stay close of the SQL request, you can simply have a function that will fulfill an access pattern. No need for ORM.
- ponyous 5y ago
  Yeah, I have no problem with minimum ORM (prepared statements type of thing) - That's why I am asking the question, Prisma seems a bit too much. Usually I just use simple ORM helpers (get by primary key for example) and anything complex is raw sql. What I am looking for is ideally something that helps with type saftey and seeds/migrations/schema creation.
  - topicseed 5y ago
    Try Knex!
  - domlebo70 5y ago
    https://github.com/gajus/slonik https://github.com/gajus/slonik
  - heisenbit 5y ago
    I'm wondering at the moment whether Knex (solid query builder and migration) and Objection.js would not do this trick. That combo seems to give me json validation which is nice and seemingly both a way to handle entities and graphs in an efficient way.
  - gmac 5y ago
    https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/ (no built-in migration support, though)
  - 5y ago

loloquwowndueo 5y ago

“ Application developers should care about data – not SQL” Anyone who has been bitten by an ORM generating inefficient SQL (and subsequent having to learn and care about SQL) knows the above not to be true.

whatl3y 5y ago
While some people are hard lined enough on their anti-ORM stance that it sort of becomes weird, I agree with you that my beef with ORMs comes from being burned before a couple of times by a super inefficient aggregation ActiveRecord did on GROUP BY queries that it 1. not only took a really long time to figure out why a particular page in our app was loading slow but 2. we ended up having to write raw SQL to fix it. I think the answer of whether to use one depends on the type and load/volume of app you're working with combined with the dynamics, size, and skill level of your team(s). I'm extremely comfortable writing, profiling, query planning, and debugging SQL queries. Others aren't, and therefore having an ORM to query data in the DB with the syntax of the language you're using in your projects makes way more sense, if nothing other in order to speed your team up.
- cknoxrun 5y ago
  Not sure when you used ActiveRecord, but slow query logging helps a lot to identify these issues. I also appreciate that in the docs for ActiveRecord they make it very clear that jumping to raw SQL is absolutely fine and normal, and they make the interface for doing that very nice.
nikolasburk 5y ago
This statement is certainly provocative (great that it was the first thing picked up here :D) but I'm happy to explain our rationale for this a bit more. SQL is an impressive technology and has stood the test of time! Yet, we claim that it's not the best tool for application developers who are paid to implement value-adding features for their organizations. SQL is complex, it's easy to shoot yourself in the foot with and its data model (relational data / tables) is far away from the one application developers have (nested data / objects) when working in JS/TS. Mapping relational data to objects incurs a mental as well as a practical cost! This is why we believe that in the majority of cases (which for most apps are fairly straightforward CRUD operations) developers shouldn't pay that cost. They should have an API that feels natural and makes them productive. That being said, for the 5% of queries that need certain optimizations, Prisma allows you to drop down to raw SQL and make sure your desired SQL statements are sent to the DB. I see Prisma somewhat analogous to GraphQL on the frontend, where a similar claim could be: "Frontend developers should care about data, not REST endpoints". GraphQL liberates frontend developers from thinking about where to get their data from and how to assemble it into the structures they need. Prisma does the same by giving application developers a familiar and intuitive API.

deepstack 5y ago

Hmm, how does this compare to sequelize? Seems like the only reason to use prisma is the GraphQL integration. If anyone has used both please share. I've being mainly using sequelize and have being quite happy with it.

nikolasburk 5y ago
Hey, Nikolas from Prisma here! Can you elaborate what exactly you mean with "GraphQL integration"? You might be referring to Prisma 1 which was a "GraphQL layer for your database". Prisma 2 (which we are referring to with this article) doesn't have a native GraphQL integration any more :) Prisma is very different from Sequelize in various ways (see our docs [1]): - Your data model lives in the Prisma schema - Database access doesn't happen via model instances but via the Prisma Client API [2] which always returns plain JS objects making your queries much easier to reason about - Prisma Migrate auto-generates migrations based on your data model (and lets you customize these migrations when needed) - Prisma comes with Prisma Studio out of the box – a modern database GUI - Prisma is not a community-project but built by a VC-funded company – We care a lot about our community, documentation, and providing support (something we've seen lots of developers complain about with other ORMs) [1] https://www.prisma.io/docs/concepts/more/comparisons/prisma-and-sequelize https://www.prisma.io/docs/concepts/more/comparisons/prisma-... [2] https://www.prisma.io/client https://www.prisma.io/client
- deepstack 5y ago
  >Prisma is not a community-project but built by a VC-funded company Thanks for clarifying this. I know there tend to be a kneejerk reaction towards VC-funded software projects. How do you guys plan to make money on this?
  - nikolasburk 5y ago
    We've explained this in the blog post here: https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjeawmb#open-source-and-beyond https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjea... I think this quote summarizes our plans nicely: Prisma's vision is to democratize the custom data access layer used by companies like Facebook, Twitter and Airbnb and make it available to development teams and organizations of all sizes. The open-source ORM we're launching today will of course remain open-source and we'll keep investing into it since it's be the foundation for the commercial tools that folks will be able to use on top.

SlackingOff123 5y ago

I don't have much experience with node.js, so this question might sound silly. I don't see anything about database support in the blog post. Is Prisma enough to work with a PostgreSQL database from node.js? If not, what else am I missing?

atraac 5y ago
Prisma does support Postgres. https://www.prisma.io/docs/reference/database-reference/supported-databases https://www.prisma.io/docs/reference/database-reference/supp...
deleted 5y ago
[deleted]
Sujan 5y ago
Easy to miss in the long blog post: > Prisma currently supports PostgreSQL, MySQL, SQLite, SQL Server (Preview). A connector for MongoDB is in the works, sign up for the Early Access program here (https://prisma103696.typeform.com/to/FriDuIeM https://prisma103696.typeform.com/to/FriDuIeM).

brap 5y ago

I’ve been using Prisma for a while and I quite like it. Best ORM for TypeScript I’ve used. My biggest issue with it is testability. Sure, I can mock the Prisma client in tests with Jest or something, but if I want to test state I pretty much have to reimplement an in-memory DB using JS mocks. I can also connect to a real DB made for testing but it’s quite overkill, I’m usually not interested in testing Prisma itself, just my own code. I wish Prisma had test mode, where you could replace the client with a temporary in-memory SQLite DB without writing tons of boilerplate. A drop-in replacement for PrismaClient for tests would have been wonderful.

high_density 5y ago
using tmpfs... it'll help a bit (I used mysql-on-tmpfs before)
vbsteven 5y ago
Could you elaborate on why you find a real DB overkill for testing purposes? Typically you would have a set of unit tests which test your code only and use mocks for external dependencies, in this case you would mock Prisma. Tests involving DB state are not unit tests anymore and require a bit more setup but most frameworks provide a test harness/runner to quickly spin up a part of your app with dependencies resolved (instead of mocked) so you can call controller/handler/service methods directly and verify their behavior. The boilerplate for this should mostly be limited to switching out an environment variable for the database connection and maybe setup some fixtures. Is this not possible in Prisma?
ragnese 5y ago
Isn't that pretty much always the dilemma with database stuff and testing? On the one hand, you can wrap your DB operations in some kind of mockable interface(s), and then test your business logic. On the other hand, you really need to test that the actual SQL ops work anyway- what if you screwed up a foreign key constraint?- that wouldn't show up in your business logic tests or your in-memory SQLite or whatever.
matthewmueller 5y ago
Thanks for this feedback. We're very aware of this problem and are are actually working on a guide for working with Jest right now. It's a tricky problem because our use of the type-system is quite complex. I quite like your idea of a test mode or maybe a mock client that we generate.

dickfickling 5y ago

I LOVE Prisma. I’ve used Django, SQLAlchemy, Sequelize, Knex, and TypeORM in the past. all had rough edges that continually frustrated me or didn’t provide the functionality i needed. Prisma is different. It’s absolutely got rough edges, but the extremely strong type safety makes Sequelize look like a joke. The query engine itself, written in rust, combines and optimizes queries inside every tick of the event loop so GraphQL N+1 issues are a thing of the past. Also, the team and community behind it are amazing! I never thought having an active dev community behind an ORM would be important, but as the author of Sequelize-Typescript was forced to abandon it late last year and the author of TypeORM was also pretty much absent, Prisma was a breath of fresh air. I REALLY hope they can find a way to build a sustainable business out of it. Support packages, feature development contracts, something to keep them financially incentivized to keep making it better. Happy to answer any questions about my experience using it if anyone has any.

brap 5y ago
> GraphQL N+1 issues are a thing of the past. Huh, care to explain this one? I’m using Prisma with Apollo Server without doing anything fancy in my resolvers. I just assumed I’m getting N+1 issues but didn’t bother to optimize yet.
- dickfickling 5y ago
  in short the separate engine process allows them to combine every findX call you make during one tick of the event loop into a single SQL query, following the dataloader pattern, so you don’t have to implement it yourself. i’m sure @nikolasburk can shed some more light if you’re interested.
  - eurasiantiger 5y ago
    I have a feeling that does not work at all in non-trivial scenarios, e.g. if both composite keys and date range matching are required to resolve a reference.
    - 5y ago

Zealotux 5y ago

How is Prisma's support (if any) of Mongo? I use it in combination of Postgres for prototyping and I'm wondering if they play well together.

codethief 5y ago
See https://news.ycombinator.com/item?id=26888427 https://news.ycombinator.com/item?id=26888427

CGamesPlay 5y ago

I have adopted Prisma in my latest project and I have mixed feelings about it. - The generated client is top-tier. Fully specified in TypeScript with intelligent types that can be extended by the user. - The schema language is great. It provides a cohesive experience that can fully express your database structure, and it also provides a migration framework to manage that structure's evolution. - There's no hook for implementing access control at the model level, so you end up needing to create a higher-level API around the base queries to implement these yourself, which is a fairly large investment. I'd love to see a pair of functions that can modify the query before it gets sent to the Prisma engine to add extra query values, and a second function that can filter models before they are returned to the caller. Where Prisma falls short is in testing. The testing story in Prisma is that you can either use a live database, or you can completely stub out all calls to Prisma in your application. The latter means you end up writing a bunch of tests for implementation rather than for behavior, or you end up manually writing an in-memory database that fits the Prisma API. The former means that you need to completely recreate your database after every test case. The discussions on the Github seem to indicate that the old "wrap the test in a transaction" trick is forbidden, and Prisma seems architecturally set up to ensure that you can't even hack this behavior in. All in all, we probably won't switch away from it, but I will continue to look for a better way to test my endpoints.

agustif 5y ago
Hey totally off-topic maybe as it's not prisma-related/required. What do you think of using something like msw.io for mocking your endpoints as needed?
- tor291674 5y ago
  > msw.io The website is https://mswjs.io/ https://mswjs.io/
kami8845 5y ago
While depending on a live DB for testing isn't great, why not just blow away database state after every test by running TRUNCATE / DELETE against all tables? DELETE especially is very fast (couple ms) if you're not inserting large amounts of data during your test runs.

RivieraKid 5y ago

How does it compare to MikroORM? I was researching different ORM options and almost wanted to give up until I discovered MikroORM, which is simply great. Edit: After quickly going through the intro, I prefer MikroORM, it's simpler.

deleted 5y ago
[deleted]
cjpb 5y ago
I've tried Prisma, TypeORM and MikroORM and I'm certainly the most impressed with MikroORM. It's simple and the use of identity map within a unit of work, tied to a request context (for example), is just brilliant. The handling of relations (with configurable loading strategies) and other features such as Embeddables and Filters make it a real joy to use. And if at any point I can't achieve something with MikroORM itself (which generally in my case is calling a PostgreSQL function), I can easily grab the underlying Query Builder from Knex. It also has the tooling to generate a schema from your Entities, or generate Entities from an existing schema - so it's easy to get started on something new or existing.

seer 5y ago

I know prism adds soo much more than just data access for your project, but for just replacing ORMs I think I really prefer the approach of https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped where you have raw sql files / template literals and it will create types for parameters and results.

nickreese 5y ago
Pgtyped made sql+typescript a pleasure.

daralthus 5y ago

Can someone compare to Hasura please? What has been your experience?

terrortrain 5y ago
I came here with the same question. Hasura is really awesome, so far as I have used it. Now I gotta look into prisma I almost wonder if they aren't mutually exclusive. With hasura, you need to run your own server anyways, for auth or special cases. Maybe that server could run prisma? Let hasura do the migrations, and prisma track it?
nwienert 5y ago
I use Hasura and generally like it, it certainly has some sharp edges, but overall has worked. I think Hasura has much richer GraphQL support, which I pair with gqless[0] to get what I think is a much nicer client side / ORM experience overall. Other upsides are a much better RBAC column/row permissions, migrations with up/down, a better admin UI. [0] https://gqless.com https://gqless.com
- sbacic 5y ago
  What sharp edges are you referring to? I find that with new tech, I'm more interested in what it can't do rather than what it can.
  - nwienert 5y ago
    Hard to remember them all now, but definitely had a number of bugs I've ran into, most able to be worked around. For example a recent one was a huge slowdown in a simple query that should be optimized[0], still have no great solution for it or attached to any roadmap. One big one is at some point you need caching on a query level, and for that you have to purchase enterprise. I suppose they need to make money somehow, and it's a smart level to do it because it's almost impossible to not need caching at some fairly early stage. It would be nice if they let you test it out without "Contact Sales", and while there may be some way to wrap it from above, I don't think it's very easy. A meta critique would be the project seems to have less momentum than Prisma. Releases aren't as frequent or large, and I'd have much preferred they double down on PG and keep adding query abilities, performance, etc, instead of expanding database engines. [0] https://github.com/hasura/graphql-engine/issues/5745 https://github.com/hasura/graphql-engine/issues/5745

nickreese 5y ago

For those of you that want typed SQL queries check out pgtyped[1]. Using it in production and it is great for writing arbitrary SQL queries and getting full typescript support. [1] https://github.com/adelsz/pgtyped https://github.com/adelsz/pgtyped

nikolasburk 5y ago
pgtyped is awesome! We mention it along with similar tools like Slonik and Zapatos in our docs here: https://www.prisma.io/docs/concepts/overview/should-you-use-prisma#-you-want-to-use-raw-type-safe-sql-for-querying-your-database https://www.prisma.io/docs/concepts/overview/should-you-use-...

agustif 5y ago

Oh also, Blitz.js is a nextjs fullstack framework that uses and autogenerates prisma code to work with. Also FoalTS is a nice small framework for building rest endpoints with TypeScript, and recently landed @prisma support/documentation besides typeorm. Just random fyi, hope someone finds it useful if they wan't to try prisma in a more batteries included package.

yewenjie 5y ago

I am a noob in these matters which one is advised if one is to start a GraphQL API from the beginning - use DBs that directly provide GraphQL endpoints such as Fauna, Upstash, etc. - use an ORM with more traditional DBs. What are the pros and cons of each?

elitan 5y ago
I prefer having the database as a single source of truth and use something like [Hasura](https://nhost.io https://nhost.io) to generate the GraphQL API.
- ic4l 5y ago
  I second this, Hasura is a solid choice.
- ridicter 5y ago
  I tried out nhost a few weeks ago and it was great!
databrecht 5y ago
There is value in both, at Fauna we provide GraphQL out the box. Using Fauna directly would eliminate an indirection and is probably slightly more efficient. However, if there is a GraphQL layer like Prisma in between you could essentially change to any database with less impact on your application. This is tremendously interesting for people who develop frameworks, using prisma gives them the advantage of supporting multiple databases immediately. Or for application developers it could allow you to move from a non-scalable database to a scalable database once it becomes necessary or simply just switch databases if the database maintenance is causing you grief. I'm for one looking forward to Prisma supporting Fauna since if the interface is the same, there are even less reasons not to choose a scalable managed database instead of managing your own db :). And I would say that Prismas interface is quite great! Note: the performance impact does depend heavily on whether your database maps well on ORMs. Traditional databases have an impedance missmatch when it comes to translating tables to an objet format. Graph databases or the way Fauna works (documents with relations and map/reduce-like joins) map well on ORMs so the performance impact would be small.

ARussell 5y ago

I'm sure a lot of hard work went into this, so I mean no offense here when I give my honest feelings. The big differences between v1 and v2 make me uneasy. I am reminded of the constant API churn of React-Router, or the complete change from AngularJS to Angular. This approach makes me very hesitant to learn the library, because I am afraid of having the choice of painful upgrade or a dead dependency down the road. I am also wary of the library being VC-funded, because I am afraid of what kinds of features will be held at ransom down the line once they need to start making money.

gmac 5y ago

I've found this a very helpful summary of TypeScript SQL libraries: https://phiresky.github.io/blog/2020/sql-libs-for-typescript/ https://phiresky.github.io/blog/2020/sql-libs-for-typescript...

heroic 5y ago

We tried converting from Sequelize to Prisma and learned transactions were not fully supported... Can't build an app without transactions

arcturus17 5y ago
Is this for real? And what are people building that wouldn't need this?
- nikolasburk 5y ago
  Transactions are supported in Prisma, see this guide in our docs [1]. I guess the post refers to our opinionated stance on "long-running transactions" which Prisma indeed does not at the moment. The best resources to learn about this are on GitHub [2] and our blog [3]. [1] https://www.prisma.io/docs/guides/performance-and-optimization/prisma-client-transactions-guide https://www.prisma.io/docs/guides/performance-and-optimizati... [2] https://github.com/prisma/prisma/issues/1844 https://github.com/prisma/prisma/issues/1844 [3] https://www.prisma.io/blog/how-prisma-supports-transactions-x45s1d5l0ww1 https://www.prisma.io/blog/how-prisma-supports-transactions-...

steipete 5y ago

How are they going to make money?

nikolasburk 5y ago
We've explained this in the blog post here: https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjeawmb#open-source-and-beyond https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjea... I think this quote summarizes our plans nicely: Prisma's vision is to democratize the custom data access layer used by companies like Facebook, Twitter and Airbnb and make it available to development teams and organizations of all sizes. The open-source ORM we're launching today will of course remain open-source and we'll keep investing into it since it's be the foundation for the commercial tools that folks will be able to use on top.
- goliatone 5y ago
  How does “democratize the custom data access layer” make money?
  - vptr 5y ago
    I have no idea what this means either. Sounds like a bunch of buzzwords about nothing.
    - nikolasburk 5y ago
      It means that Prisma will provide a data access layer (we call it "application data platform" [1]) similar to the custom data access layers built by big companies [2] (e.g. TAO by Facebook or Strato by Twitter) that enables application developers to better access their databases. We've explained that in the blog post here in the "Open-source, and beyond"-section [3]. Does that help? :) [1] https://imgur.com/O1lwo0v.png https://imgur.com/O1lwo0v.png [2] https://imgur.com/Hb9VOWN.png https://imgur.com/Hb9VOWN.png [3] https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjeawmb#open-source-and-beyond https://www.prisma.io/blog/prisma-the-complete-orm-inw24qjea...

vsskanth 5y ago

What's the most recommended .net equivalent

Coxa 5y ago

Have been experimenting with mammoth [1] for postgresql and am quite happy with how close it is to actual SQL. [1] https://github.com/Ff00ff/mammoth https://github.com/Ff00ff/mammoth

pistoriusp 5y ago

We've been using Prisma in RedwoodJS since the early days. It's a great ORM that they're constantly improving, I'm super excited for the future!

segmondy 5y ago

I'm not a fan of ORM, never been and never will be. https://en.wikipedia.org/wiki/Object%E2%80%93relational_impedance_mismatch https://en.wikipedia.org/wiki/Object%E2%80%93relational_impe... But my gosh "Application developers should care about data – not SQL"

spmurrayzzz 5y ago
That line triggered me as well. I have built hundreds of applications on top of databases w/ sql and nosql, and from that experience— the notion that a single ORM abstraction somehow ameliorates the burden of caring about how your queries are written is alarming to me.

skrebbel 5y ago

IMO any discussion about Node/TypeScript data access tools deserves a reference to Zapatos, which sort of is the anti-Prisma. It has all the type safety with none of the ORM (and it's Postgres-specific, for better and worse). I think it's got one of the best designed APIs I've come across. https://jawj.github.io/zapatos/ https://jawj.github.io/zapatos/

parhamn 5y ago
> prioritis[ing] ease of switching to another database tomorrow over effective use of this database today, are a source of misery. hah. This looks cool, thanks for sharing!
nikolasburk 5y ago
Fully agree, Zapatos is super nice – and so are similar tools like pgtyped and Slonik. We actually mention all these in our docs here: https://www.prisma.io/docs/concepts/overview/should-you-use-prisma#-you-want-to-use-raw-type-safe-sql-for-querying-your-database https://www.prisma.io/docs/concepts/overview/should-you-use-... I think the main difference of these libraries compared to Prisma is the level of abstraction. If you want to work with SQL and you appreciate type-safety, then all of these tools will be fabulous options for you! If you want to work on a somewhat higher level of abstraction but still have full type-safety, Prisma will be more appropriate.
smt88 5y ago
PgTyped is similar, and it's superior to any other data access layer I've ever used. Ever.
- jadbox 5y ago
  Have you compared PgTyped to Zapatos (I haven't yet).
  - smt88 5y ago
    Not yet, but I will at some point. I don't really have any pain points with pgTyped yet.

bwship 5y ago

What is the business model for them? It seems that an ORM in and of itself is not sustainable, especially one that is free.

nikolasburk 5y ago
https://news.ycombinator.com/item?id=26888735 https://news.ycombinator.com/item?id=26888735

htkien 5y ago

I am over ORMs. I am looking at the documentation for Prisma Client at the moment, and I just think to myself "yet another ORM I have to learn". I have learnt so many ORMs, it is just stupid. SQL is SQL. I wish I had spent all that time further developing my SQL skills rather than learning the latest ORMs API. For my latest large project, I just used SQL and I am happy. All I did was add some code to make sure the snake case was converted to camel case. Things like returning arrays of child relations can all be done in SQL these days with things like json_agg and json_build_object and so on. Half of my SQL on the other hand doesn't even map to an ORM. Where is the insert ... select ... where not exists ... These things aren't even possible in the ORM concept model.

zackify 5y ago
It took me all of 1 hour to learn how to use prisma. It’s not as hard as you make it seem. They have a vs code extension for editing the prisma schema. It’s not hard to see that you make fields “String” @unique, etc. Just make one model and that’s 80% of anything you ever need. Want to make a relation? Make a new model model Posts { users User[] } Hit save, it adds the required code to relate it to the User model. Run the generate command. Make a client instance. Create something: db.NameOfModel.create() And as you’re typing, typescript is auto completing it. There’s barely anything else to learn. And it’s a quick doc search away. Don’t hate on it because you love sql, it’s a great tool.
- htkien 5y ago
  >It took me all of 1 hour to learn how to use prisma. That is not how this works at all. You don't know what you don't know until you need "how do I do this query in prisma". You then spend an hour trying to figure it out, and maybe it isn't possible, then on to the next thing. It takes more than an hour to learn SQL, so if it takes you an hour to learn Prisma, you are missing something.
  - joshmanders 5y ago
    Have you even looked at Prisma's docs? I would rather forget everything about Prisma the second I wake up in the morning and have to read their docs on how to do everything all over again, every single day, than try to understand what the heck is going on in SQL's docs.

zackify 5y ago

For years node had pretty bad libraries for interacting with databases. Prisma is the first time it all just makes sense. The code generation, auto migrating without any code, automatic crud resolvers with nexus, the list goes on. After using it, I don’t know how you can use any other language for backend. It would just take you much longer and require so much extra work. Nothing like prisma exists in other languages.

knodi 5y ago

I used Prisma with TypeScript for rapid prototyping. It did what it said and did it well. I would highly recommend giving this a try.

fuadnafiz98 5y ago

Is it a good suggestion to use prisma as a beginner other than using some low level query builders like knex.js?

nerdkid93 5y ago

Over a year ago, I was investigating using Prisma to be the ORM for a GraphQL API of a Postgres database. When doing a proof-of-concept, I discovered that under the hood @prisma/client was spinning up it's own GraphQL server that it would send requests to in order to generate SQL to send to postgres. This extra middleware layer between my frontend code and postgres generated some pretty poor performing queries that took 50% longer to complete than the queries generated by using Hasura as our whole GraphQL API. A quick glance at the @prisma/client code makes it seem like this pattern is still the case, since they have an "engine-core" package that downloads a binary server behind the scenes and runs it on a free port in the background.

vptr 5y ago
Yup, would not touch Prisma with a 10 foot pole
camjohnson26 5y ago
That extra layer gives them flexibility to combine queries and cache
inshadows 5y ago
> they have an "engine-core" package that downloads a binary server behind the scenes and runs it on a free port in the background O_____O
thedavidprice 5y ago
I'm on the RedwoodJS core team and can 100% confirm early performance issues. That's no longer been the case recently. I've seen bulk operations perform just fine and even data pipeline use cases. Now the issue is DB performance in a serverless infra, which needs extra set up and config to perform consistently and at scale.

codeulike 5y ago

New idiom - "Well that was a complete ORM" (sorry just a joke, ORMs do have their place and this looks useful. I'd think of Prisma as a lightweight ORM because it doesn't try to do "Business Rules" as they are known. But then, trying to do Business Rules will generally turn everything into a nightmare anyway so maybe lightweight ORM is the way to go)

mst 5y ago
Even as an ORM author this made me laugh. ORMs are useful. ORMs aren't always the right answer. ORMs that don't let you mix and match so you can bypass any given layer of abstraction as required annoy the pants off me ... usually even more than anti-ORM zealouts annoy the pants off me. So, yeah, joke appreciated :D

metta2uall 5y ago

Prisma looks quite good but what held me back is the out-of-process "engine" that handles all queries and talks to the DB. I would imagine all this inter-process communication adds a decent amount of overhead.

subsection1h 5y ago

My team experimented with Prisma, and we ended up deciding to continue using raw SQL. Each of us has 10-20 years of experience writing SQL for PostgreSQL, so it wasn't a surprise that we decided against using an ORM yet again. But Prisma is probably the best ORM for Node.js that we've tried. For anyone who uses PostgreSQL and is interested in Prisma, check out the following message, which has a section that includes a list of features that were deemed out-of-scope (e.g., bulk upserts): https://github.com/prisma/prisma/issues/4998#issuecomment-766742955 https://github.com/prisma/prisma/issues/4998#issuecomment-76...

vaughan 5y ago

I think its unfortunate that Prisma is only server-side due to its Rust-based native DB module. I think we can achieve a huge simplification in the industry if we develop a universal state-management solution that runs in the frontend and backend. Without a consistent model, we are forced to write so much additional code to manage caching, optimistic UI updates, and offline capabilities. Current RDBMS' are not ideal (most data is better represented as a graph), but because the relational model is so widely used in the backend, they are a good candidate for a universal data store on frontend and backend. And it is possible to represent graph-like structures in RDBMS' too, but it makes SQL querying very unfriendly. GraphQL is an ideal language for declaratively specifying what data you need for the UI layer. If you doubt this, play around with the [Github GraphQL API][1]. It's an incredible experience to be able to explore and pluck exactly what you need. SQL and REST don't come close to this experience. But GraphQL is essentially providing us a nicer way to write SQL compared to using JOINs, and to output it in a nested format for convenient rendering with nice typing. But it lacks a huge amount of flexibility. So we should keep GraphQL as our API, but we should implement it client-side against a data model similar to what we use in our cloud db: SQL, and then do real-time syncing or use it as the model for our server-cache. An added benefit is we don't have to worry anymore about what is local-state and what is server-persisted, or worry about choosing a good state management solution client-side. The necessary pieces to make this happen don't exist at the moment, but I would have liked to use Prisma as the DB API for in-browser SQLite in the beginning. I think there is then the opportunity to go full-stack and offer developers a client-side GraphQL library that talks to an in-browser SQL DB and to end the constant turnover in state-management libraries. I think every frontend developer is overwhelmed at this point by the proliferation of these libraries, and the simplicity they go seeking in things like "just use React.Context api", don't offer them what they will eventually need which is optimistic UI updates, offline modes, real-time collaboration, local-first experiences, etc. I think we are all still in search of the right state management solution and it would be cool if Prisma did it! [1]: https://docs.github.com/en/graphql/overview/explorer https://docs.github.com/en/graphql/overview/explorer

kofejnik 5y ago

Used it once, it is nice(-ish) for simple use cases, but unfortunately it doesn't support working with multiple postgres schemas, which is surprising given that many complex apps use them to namespace their DBs. It was a total showstopper for us and we're back to writing raw sql for now

thatwasunusual 5y ago

A few months ago I spent a week testing all of the available ORMs for JS/TS, and Prisma came out on top. That said, Prisma isn't exceptionally good in any way, it's just not as bad as the alternatives; Mikro-ORM, TypeORM, Sequelize etc.

kkarimi 5y ago

Prisma is singlehandedly making my work life easier and better every day, can’t fault it much at all. Really lovely experience and the public slack community is super helpful too!

hmsimha 5y ago

I have mixed feelings about Prisma. I do think it might be the best general-purpose ORM for relational databases in the Node landscape, and support for Typescript with autogenerated interfaces is amazing. But it seems to fall short in some ways as well (my experience with ORMs in the past is limited to ActiveRecord and Mongoose, both of which I haven't touched in years). I've only been using Prisma for ~2 months, for an internal application on which I'm the sole developer, and I'll keep using it. But given a new project and freedom to choose, there's a very good chance I'd go with another ORM depending on the use case. One of the things that is most perplexing to me is the inability to autogenerate a seed file from existing data, to reseed a new database. This would be incredibly helpful for testing and working with staging data. For example, we have a staging database and staging server, and want to be able to reseed the database with some data set, but don't want to write all the data inserts by hand. I'm sure there are many ways to avoid doing this (db-specific export/import, scripting the inserts in a loop over a collection of arrays of values which you've curated by hand, or in our case just copying the sqlite db file). Still, Prisma's story around seeding and data fixtures in general currently leaves a lot to be desired. There have also been many rough edges I've run into around shaping results (getting category names which have been applied to all blog posts by a given user, for example), and applying schema changes, but I'm not willing to rule out user error / inexperience for many of these

eloff 5y ago

I don't like ORMs, but Prisma is one of the better ones. It avoids a lot of shortcomings of popular ORMs. I hope they find a way to make it work as a company. I've been following them over the years from the beginning of their journey through various pivots. To use an ORM effectively you must learn both the API of the ORM and SQL. It does not absolve you from learning SQL, which I think was one of the unstated attractions to junior developers. Then you have to map between the API of the ORM and how it translates that to SQL under the hood. Then you have to understand how it handles caching and sessions and how that all works under the hood. This has been the source of so much complexity and so many bugs over the years that I no longer think the benefits are worth the cost. As always, there are exceptions and caveats, but I now believe it's better to use SQL directly than to use an ORM. In general there is too much complexity in all the layers of abstraction in software development these days, and I think the industry is strangely blind to the consequences of this. Complexity is death to software, and it should not be taken on lightly. The entire craft of a software engineer boils down to eliminating complexity and simplifying problems, the better you can do that, the more productive an engineer you will be.[1] [1] https://github.com/sqljoy/sqljoy/blob/master/docs/pages/orm.md https://github.com/sqljoy/sqljoy/blob/master/docs/pages/orm....

nawgz 5y ago
> I think the industry is strangely blind to the consequences of this Well, I think if you're not blind to those things to some degree, you're stuck forever in a best-practices search, which I feel like more often than not ends up implying you have to rewrite your stack. For example, I do most of my development thru Hasura now. It writes insanely performant SQL queries translated directly from GraphQL. As a data consumer, you only have to worry about the shape of the data you want, and none of the implementation details. There is one endpoint, and you pass it queries against the schema it exposes. Implementation details are abstracted heavily here, but in a "good" separation of concerns way. I will never hand-write SQL again. Why would I? My front-ends can load everything in my data model expressively and with type safety thanks to graphql-codegen. Now imagine you read this and realize you work in a completely different method and this answers some of your problems. You may start parallel development, but you certainly can't stop forward progress just to evaluate your stack. So I think the blinders are key to progressing in the short term despite the productivity losses you're taking in the long term, and then when you phrase it like this it is surely no surprise companies behave like that.

karmakaze 5y ago

I was reading through the 'where' cases to see how complex queries are composed. I couldn't find any examples. e.g. WHERE id IN (<subquery>) if I built up <subquery> using the ORM. The other uncommon thing I look for is eliminating N+1 not just based on a given query and related entities, but given a starting collection and loading their related entities and further related entities. Icing is if it can do all the above while making intermediate results asynchronously available as it works through it all.

wasd 5y ago

How's the support for window functions? One thing I like about ActiveRecord is it's lazily evaluated and you compose queries. You can do p = Post.where(published: true); if x; p.where(x: true). Is that supported? Checked here for window function support. https://www.prisma.io/docs/concepts/components/prisma-client/aggregation-grouping-summarizing https://www.prisma.io/docs/concepts/components/prisma-client...

beders 5y ago

From the web page: "Application developers should care about data – not SQL" That is fundamentally wrong - or at least - it is very limiting. Think very hard about adopting a framework that tries to shield you from SQL. Because at the end of the day, you will be looking at SELECTS and INSERTS in your logs because you are wondering why things are so slow or why your memory usage skyrockets. It looks like Prisma allows you to go to raw SQL if you must, yet you won't have a good time using some of PostgreSQL more advanced features. If your domain model is simple and will remain simple in the future, then - by all means - use a builder that creates queries from your domain model. Use a single-source-of-truth approach that is usable from the back-end and front-end. In other cases, where your domain model changes over time, be very careful when choosing an ORM but extra double careful in picking the right data store.

tobyhinloopen 5y ago

Meanwhile I just want to write my migrations in plain SQL. Why do we care so much about hiding SQL, it’s easy.

gsvclass 5y ago

GraphJin is very similar but in Go. Also you can either embed the whole service as a library or just the GraphQL to SQL compiler. Another advantage of GraphJin is that the you write the queries in pure GraphQL not a library specific API. https://github.com/dosco/graphjin https://github.com/dosco/graphjin

Tronno 5y ago

The only time I have had to query a database using JS/TS is in React Native + SQLite. However, as far as I can tell, Prisma has no support for this stack, so TypeORM remains the only practical choice here - rough edges and all. I would love to try Prisma otherwise.

dang 5y ago

Past related threads: Prisma Raises $12M Series A - https://news.ycombinator.com/item?id=23651605 https://news.ycombinator.com/item?id=23651605 - June 2020 (111 comments) Prisma 2.0 – Type-safe and auto-generated database client - https://news.ycombinator.com/item?id=23466834 https://news.ycombinator.com/item?id=23466834 - June 2020 (107 comments) Prisma 2.0 Beta: Type-safe Database Access - https://news.ycombinator.com/item?id=22739121 https://news.ycombinator.com/item?id=22739121 - March 2020 (122 comments) Comparing Database Types - https://news.ycombinator.com/item?id=21060866 https://news.ycombinator.com/item?id=21060866 - Sept 2019 (170 comments) Prisma – Database tools for modern application development - https://news.ycombinator.com/item?id=19598287 https://news.ycombinator.com/item?id=19598287 - April 2019 (83 comments) Show HN: Prisma – Turn Any Database into a GraphQL API - https://news.ycombinator.com/item?id=17076202 https://news.ycombinator.com/item?id=17076202 - May 2018 (16 comments) Prisma Cloud – A GraphQL Database Platform - https://news.ycombinator.com/item?id=16529450 https://news.ycombinator.com/item?id=16529450 - March 2018 (9 comments) Prisma – An open-source GraphQL API layer for your database - https://news.ycombinator.com/item?id=16160803 https://news.ycombinator.com/item?id=16160803 - Jan 2018 (34 comments) Prisma: Turn your database into a real time GraphQL API - https://news.ycombinator.com/item?id=16159874 https://news.ycombinator.com/item?id=16159874 - Jan 2018 (9 comments)

nikolasburk 5y ago
Nice, thank you for digging these up!

debug-desperado 5y ago

I'd still take Hibernate and Entity Framework over any of the Node ORMs I've seen, including Prisma. The former usually have the feature you need to generate the queries you want, but you just haven't read enough of the docs to understand how to do so. The latter straight up lack the functionality and lack sufficient docs.

oso2k 5y ago

Maybe it's too late to change the name. When Palo Alto Networks acquired Twistlock (Container Scanning/Security products) 2 years ago [0], they folded it in & renamed it to Prisma Cloud [1]. Food for thought if prisma.io team is watching. [0] https://www.paloaltonetworks.com/company/press/2019/palo-alto-networks-completes-acquisition-of-twistlock https://www.paloaltonetworks.com/company/press/2019/palo-alt... [1] https://blog.paloaltonetworks.com/2019/11/cloud-prisma-cloud-compute-edition/ https://blog.paloaltonetworks.com/2019/11/cloud-prisma-cloud...

kache_ 5y ago

orm bad

rafaelvasco 5y ago

I use Mikro-ORM not Prisma but I couldn't help but use an ORM in my project. Dealing with Mongodb schemas and queries directly, and modelling associations between entities, hiding certain fields on select, selectively populating joined @ManyToOne properties and all that DB stuff, was a nightmare to do by hand. Changed everything to ORM and all my problems were solved. Annotated entities, annotated properties, queries, joins, hidden fields, @OnCreate triggers etc, everything nicely handled for me. So yeah, I love ORMs. Have yet to find something nicer than .NET Entity Framework + LINQ though. That stuff is amazing.

benho 5y ago

I dont have much to add technically, I just want to show my gratitude, it has been very helpful for one of my projects.

_carl_2_2_m__ 5y ago

I've been hunting for the perfect solution to reduce the boilerplate in the "database-backend-frondent stack" for years and came to the conclusion: There is no shortcut. And we don't need one. For most non trivial applications - when I used an ORM or other abstractions over SQL - there came the point at which I needed to dive quite deep into the workings of the ORM. However, learning how your DB and SQL works is much better spend time than learning the complexities of an ORM. Equally important: The time saved upfront diminishes over the lifecycle of the project. Often (not always) figuring stuff out about the abstraction costs much more time and energy than writing the boilerplate. Typing out the boilerplate is boring, that's why we hate it so much. Figuring something new out? Time flies ... For my projects I've got a template for basic CRUD operations including a frontend store. Full control, easy to use and understand and only a couple of minutes to fill in the field names for a new database table or view.

thebrubaker 5y ago

ORMs can be a pain. Setting up SQL schemas and managing migrations is also slow and tedious. Prisma won me over when my friend integrated it while we were working on SpaceTraders.io - things have mostly been going well. Main issue was not getting the transaction support needed for read / compute / write locks. Solved our needs for today with Redis, but we came very close to regretting the Prisma choice. Other than that the DX is amazing and the tooling is great. I think there is a lot of promise and I'm excited as they develop more advanced DB escape hatches.