Does it have migrations yet?
I'd like to give Prisma a try, but if there's no sane way to change my schema (part of my daily backend workflow) then it's less interesting, no matter how nice the API is. For now I'll stick with Sequelize.
Prisma 2.0 – Type-safe and auto-generated database client
11–20 of 112 posts
Re: Prisma 2.0 – Type-safe and auto-generated database client
#12I empathize with the frustration that this library is trying to solve. It's pretty nifty too! Ultimately, however, I don't believe this is the correct approach. The problem with this tool, like every other multi-SQL-flavor-SQL ORM and query builder, is that it requires users to learn yet another language. In addition to Node.js and SQL, users need to learn the Prisma query language. This is not trival, and users that…
TypeORM? Zapatos maybe?
Re: Prisma 2.0 – Type-safe and auto-generated database client
#13Prisma's architecture seems novel and ... a little strange to me. It works by running a Rust engine as a subprocess and then communicating with the engine from JS land over a non-spec compliant GraphQL API. The engine holds the actual databae connection pool and does all the SQL generation and data marshalling. See https://www.prisma.io/docs/reference/tools-and-interfaces/pr... for more info on this arrangement. It h…
A few things to note:
- Prisma 1 was a completely independent server and Prisma 2 was most likely started as a rewrite of Prisma 1 so it followed the same approach
- This indirection will be removed if someone can finally land a Rust binding to NAPI (looking at you Neon binding people)
- Prisma plans to support multiple languages thus it makes sense to have an agnostic engine
- This not far from having a PG engine coded in C and interfacing with like like most libraries do anyway, javascript is just too slow for this kind of stuff
Re: Prisma 2.0 – Type-safe and auto-generated database client
#14Prisma's architecture seems novel and ... a little strange to me. It works by running a Rust engine as a subprocess and then communicating with the engine from JS land over a non-spec compliant GraphQL API. The engine holds the actual databae connection pool and does all the SQL generation and data marshalling. See https://www.prisma.io/docs/reference/tools-and-interfaces/pr... for more info on this arrangement. It h…
I don't see how useful it would be to query your database from the browser or cloudflare workers, in both cases you want the database access closer to your database to reduce the RTT. And you definitely don't want to give the browser direct access to your database - even if that were possible.
The implementation choice seems odd to me, nonetheless.
Re: Prisma 2.0 – Type-safe and auto-generated database client
#15Does it have migrations yet? I'd like to give Prisma a try, but if there's no sane way to change my schema (part of my daily backend workflow) then it's less interesting, no matter how nice the API is. For now I'll stick with Sequelize.
They have, but it's "experimental" at the moment: https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
Re: Prisma 2.0 – Type-safe and auto-generated database client
#16I empathize with the frustration that this library is trying to solve. It's pretty nifty too! Ultimately, however, I don't believe this is the correct approach. The problem with this tool, like every other multi-SQL-flavor-SQL ORM and query builder, is that it requires users to learn yet another language. In addition to Node.js and SQL, users need to learn the Prisma query language. This is not trival, and users that…
I get where you are coming from, but from your comment I am guessing you have yet to try Prisma.
I'll speak to my personal experience...
I became allergic to ORMs after experiencing much of the pain that you describe. Like you, I quickly found ORMs were simply an additional domain language / abstraction over my database that provided more pain that usefulness. Every time I wanted to make I change to the code I had to wade through tons of docs and/or stackoverflow posts by other frustrated users. If I wanted type safety I had to express and maintain types/decoders/encoders myself. Huge pain, and things always got stale leading to a massive mistrust in my data layers.
Prisma doesn't feel like those experiences. Their schema-first, client code gen approach works surprisingly well. Using the generated API feels really intuitive, and TypeScript is there the whole time providing guidance and autocomplete for me. The object tree query syntax is quite refreshing compared to the builder pattern approach taken by the alternatives. I always found the builder pattern overwhelming and often a guessing game at how to compose them.
I think Prisma doesn't try to be too clever with their data API. They solve the 99% in a manner that is simple and convenient, for everything else you have the raw query API - much like other solutions.
I'd suggest giving it a try. You may like it.
Re: Prisma 2.0 – Type-safe and auto-generated database client
#17I empathize with the frustration that this library is trying to solve. It's pretty nifty too! Ultimately, however, I don't believe this is the correct approach. The problem with this tool, like every other multi-SQL-flavor-SQL ORM and query builder, is that it requires users to learn yet another language. In addition to Node.js and SQL, users need to learn the Prisma query language. This is not trival, and users that…
Specifically in Node.js, https://github.com/gajus/slonik has drastically improved the experience of writing and composing SQL queries. I am the author of Slonik.
Re: Prisma 2.0 – Type-safe and auto-generated database client
#18Does it have migrations yet? I'd like to give Prisma a try, but if there's no sane way to change my schema (part of my daily backend workflow) then it's less interesting, no matter how nice the API is. For now I'll stick with Sequelize.
Today's release unfortunately doesn't include our migration solution Prisma Migrate [1] yet. We totally understand that a lot of people want to get "database access" and "schema migrations" with the same tool/library, that's why we're focusing most of our engineering efforts on Prisma Migrate next and will hopefully be able to release that soon!
However, we do see a lot of folks using third-party migrations (like knex.js or indeed Sequelize) and then still get the benefits of Prisma Client [2] through introspection [3] for the time being. For non-critical applications we also already see lots of users who are trying out Migrate and help us improve it through constant feedback! I'd love to hear your thoughts on the current version so that we can make sure to consider your feedback and ideas for Migrate when building it out over the next few months.
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[2] https://www.prisma.io/blog/announcing-prisma-2-n0v98rzc8br1/...
[3] https://www.prisma.io/docs/reference/tools-and-interfaces/in...
Re: Prisma 2.0 – Type-safe and auto-generated database client
#19I have a lot of experience with ORMs (the Django one in particular). I'm having a hard time finding a quick overview of how Prisma's model is different. Are there any good overviews of the similarities and differences?
Re: Prisma 2.0 – Type-safe and auto-generated database client
#20Prisma's architecture seems novel and ... a little strange to me. It works by running a Rust engine as a subprocess and then communicating with the engine from JS land over a non-spec compliant GraphQL API. The engine holds the actual databae connection pool and does all the SQL generation and data marshalling. See https://www.prisma.io/docs/reference/tools-and-interfaces/pr... for more info on this arrangement. It h…
I don't see how useful it would be to query your database from the browser or cloudflare workers, in both cases you want the database access closer to your database to reduce the RTT. And you definitely don't want to give the browser direct access to your database - even if that were possible. The implementation choice seems odd to me, nonetheless.
You're totally right about connecting to your database from the edge. That said, I think JS is quickly becoming the target for a lot of hosted runtimes because it is so easy to sandbox and has the option to drop down to WASM for high performance and indirectly supporting other languages. Cloudflare Workers (and Fastly, and Superfly, and and and) are all following that path at the edge, but I think as the consensus builds around JS + WASM as a server runtime, we might see the same style of environment for more traditional workloads that might wanna connect to databases.