https://www.learnchess.ai — The chess app I always wanted (I've tried a lot of apps in the last years but they always lacked some fundamental feature and/or had terrible UX).
Hey there, thanks a lot for the feedback! As I mentioned in other threads, you can configure the output location for the generated Prisma Client library [1], node_modules is just the default. The reason why we made it the default is because it comes closest to what Node.js developers are used to and therefore fits their workflow and mental model nicely.
Also please read this Twitter thread between the lead Yarn maintainer and our CEO [2]. The gist is that we're very open to other approaches but this was the best we've come up with so far after 9 months of experimentation and lots of feedback from the community. This doesn't get easier by the variety of package managers out there and the custom workflows they sometimes employ (e.g. wrt pruning and caching). To put it in the words of our CEO: we'd be more than happy to embrace whatever package manager mechanism would enable this use case "more cleanly".
> I was really excited when Prisma1 came out. It would be understatement to mention that Prisma1 was way overpromised and nothing ever materialised.
While I can understand your sentiment, I don't think this is quite true! We've seen a number of companies very successfully adopt Prisma 1 – ultimately we realized though that the vision of building a new way for application developers to access their database can't be built on top of the JVM. At that point, we needed to make a tough judgement call and decided to rewrite Prisma in Rust. Needless to say that this was quite a challenge, but our engineers have done an absolutely outstanding job of managing this rewrite.
We certainly had a number of tough learnings, especially when it came to the variety of different DB schemas out there that we needed to support with our introspection. I'm really proud of the result though, we've built a strong and stable foundation that allows us to expand the functionality of our tools over time – this would not have been possible without the rewrite!
> With Prisma2, honestly disappointed as it is too little to show for. This is an ORM like library that supports only couple of databases with database migrations still in experimental state with broken links for workarounds[1]
Please recall that we're just launching into Beta. As I said, we now have the foundation to expand the functionality of our tools! You'll see a lot of exciting improvements and new tools from Prisma over the next few months!
Sorry about the broken links, I'm in the process of fixing most of them! In this case, the links point to the "Guides > Database workflows"-section which contains a number of helpful step-by-step tutorials for performing certain schema migrations (e.g. cascading deletes [1]) and using those with Prisma Client. (While these features are not supported by Prisma Migrate yet, you can still configure them in your DB and use Prisma Client for DB access).
pgtyped looks awesome, fantastic work! We're huge fans of type-safety at Prisma so anything that makes working with DBs type-safe is right down our alley! :D
I think one thing that distinguishes Prisma (on the longer run) from a library like pgtyped is that Prisma will enable more database workflows than just database access. With Prisma Migrate, you can alter your DB schema and keep a migration history, Prisma Studio will enable lots of DB workflows on a GUI level, and Prisma Cloud will have great integrations for teams and larger scale organizations eventually.
All that being said, because Prisma is a DB toolkit, you can also pick and choose any tools you like from it. Nothing would e.g. speak against using Prisma Migrate to run your schema migrations but keep accessing your DB with pgtyped, in fact I think this would be an awesome combination :)
Massive is great and we certainly took some inspiration from it (in fact we're friends with Dian, the author of Massive and are fans of her works).
The level of type-safety when using Prisma Client with TypeScript is indeed a major factor that sets Prisma apart from other DB libraries in general (not Massive in particular).
Would also love to hear what other people think of the two in comparison! :)
Yeah, we just published the new website today and moved around a ton of stuff. We're still in the process of cleaning things up here and there, feel free to ping me when you find more broken links :) (@nikolasburk on Twitter or Prisma Slack)
Hey, thanks a lot for the feedback (and I've seen harsher words on HN, so no worries)! I wrote most of the docs, so more than happy to take any feedback to see where it can improved!
What I'm mostly trying to refer to are ActiveRecord style ORMs in the Node.js ecosystem (such as Sequelize and TypeORM). With those libraries, you often have model objects that can get really complicated to work with, these are not plain objects but implement lots of additional behaviour for storage and retrieval of data, often times business logic as well. Compared to that, working with plain objects (which are statically and structurally typed) is a fundamentally different approach that's hopefully easier to reason (at least that's what I've found from my personal experience).
You can specify where you want to generate Prisma Client yourself, `node_modules` it's just the default.
See my response above:
> Also note that you can actually generate Prisma Client into a different location [4], so if you prefer not to have it in node_modules, that's totally possible as well.
I don't believe so, this term was coined by one of our community members and we really liked it and decided to adopt it to distinguish Prisma Client conceptually from "conventional" (for lack of a better term) node modules.
Depending on your deployment environment and workflow, there indeed can be special requirements wrt deployment (also because Prisma Client relies on a "query engine binary" [1] which needs to run as a side-process on the same machine as your application). When deploying, you need to ensure that you're selecting the right build target [2] for the binary. You can find more info in the deployment docs [3].
TLDR: Generally deployment should "just work", but there can be cases when you might have to do some extra configuration to get your app deployed.
Also note that you can actually generate Prisma Client into a different location [4], so if you prefer not to have it in node_modules, that's totally possible as well.
Nikolas from Prisma here, a realtime API for Prisma is certainly on our roadmap – as Prisma doesn't provide a GraphQL interface, this most likely will not come in the form of GraphQL subscriptions though but another (programmatic) realtime API.
However, using Nexus [1] on top of Prisma, you'll be then be able to turn Prisma's realtime API into GraphQL subscriptions. All of this is quite a bit further down the road, but certainly on our radar and part of future plans!
Prisma is a database toolkit that's used by application developers to develop server-side applications in Node.js and TypeScript (e.g. REST APIs, microservices, gRPC calls, GraphQL APIs, ..., anything that talks to a database). The main tool Prisma Client is a query builder that's used to programmatically send queries to a database from Node.js/TS.
Hasura is a "GraphQL-as-a-Service" provider that generates a GraphQL API for your database. This GraphQL API is typically accessed by frontend developers.
That setup can be great when your application doesn't require a lot of business logic and the CRUD capabilities that are exposed in the GraphQL API fit your needs (though I believe you can add business logic in Hasura by integrating serverless functions).
With Prisma, you're still in full control of your own backend application and can choose whatever tech stack you like for developing it (as long as it's Node.js-based, though Prisma Client will be in available in more languages the future)!
By the way, we also love GraphQL. We're currently brewing a new "GraphQL application framework" that can be used on top of Prisma. That way it will be possible to auto-generate resolvers for Prisma models to reduce the boilerplate you need to write, while still keeping the full control of your GraphQL schema.
Hey! Thanks a lot for sharing this, a lot of the features you mention here are already possible with Prisma 2.0 (or will be in the future). Would love to hear your thoughts on the new version :)
We are planning to eventually add commercial cloud services to make Prisma/DB workflows easier (especially for teams and larger organizations). The current OSS database toolkit will remain free forever!