Prisma 2.0 Beta: Type-safe Database Access(prisma.io)
prisma.io
Prisma 2.0 Beta: Type-safe Database Access
https://www.prisma.io/blog/prisma-2-beta-b7bcl0gd8d8e
123 comments
Is mongo support in yet? I tried the Prisma2 beta a couple of months ago and it was still on the way.
We do not have Mongo support in Prisma 2 at this point, but we have a GitHub issue to track it as a feature request: https://github.com/prisma/prisma/issues/1277
How does this compare to TypeORM? First time hearing about this project, and it looks interesting
Nikolas from the Prisma team here.
The most important thing to note here is that Prisma Client is not an ORM! [1]
Prisma doesn't map classes to tables as ORMs do and therefore doesn't suffer from the object-relational impedance mismatch. Prisma Client queries return plain old JS objects, which makes it really easy to reason about queries and returned data.
Prisma also has a query engine [2] that's implemented in Rust. This is being developed separately from the TS/JS layer above (so that in the future Prisma can support other languages as well).
Prisma also generally provides stronger type safety than TypeORM. For example, you get full type safety even for partial queries [3], you can find an example for what this looks like in this video [4].
Let me know if you have more questions about this :)
[1] https://www.prisma.io/docs/understand-prisma/prisma-in-your-...
[2] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[3] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[4] https://youtu.be/LggrE5kJ75I?t=40
The most important thing to note here is that Prisma Client is not an ORM! [1]
Prisma doesn't map classes to tables as ORMs do and therefore doesn't suffer from the object-relational impedance mismatch. Prisma Client queries return plain old JS objects, which makes it really easy to reason about queries and returned data.
Prisma also has a query engine [2] that's implemented in Rust. This is being developed separately from the TS/JS layer above (so that in the future Prisma can support other languages as well).
Prisma also generally provides stronger type safety than TypeORM. For example, you get full type safety even for partial queries [3], you can find an example for what this looks like in this video [4].
Let me know if you have more questions about this :)
[1] https://www.prisma.io/docs/understand-prisma/prisma-in-your-...
[2] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[3] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[4] https://youtu.be/LggrE5kJ75I?t=40
In the first document, all the links in the comparison table link back to the document itself instead of the documentation for the things mentioned.
Thanks, will get that fixed!
and therefore doesn't suffer from the object-relational impedance mismatch. Prisma Client queries return plain old JS objects
Is that really true? the data models are still different, relations vs js objects. Maybe you meant to say that Prisma hides and abstracts away the relational model, but the impedance mismatch is still there.
Is that really true? the data models are still different, relations vs js objects. Maybe you meant to say that Prisma hides and abstracts away the relational model, but the impedance mismatch is still there.
You still map objects to relations.
- ORMs traditionally map classes to tables.
- Prisma maps queries to structural types.
This is a key distinction that the community will need to spend some time to really get an intuitive understanding for. I think you will realise that many of the problems we discovered when using classic ORMs (often described as impedance mismatch) does not apply to Prisma. But there are sure to be other problems that we will discover over time. I am looking forward to shake this out together with the broader community over the coming years.
- Prisma maps queries to structural types.
This is a key distinction that the community will need to spend some time to really get an intuitive understanding for. I think you will realise that many of the problems we discovered when using classic ORMs (often described as impedance mismatch) does not apply to Prisma. But there are sure to be other problems that we will discover over time. I am looking forward to shake this out together with the broader community over the coming years.
Nikolas, video [4] is still set to “private”, fyi.
Ah thanks for catching this Martin, fixed!
Very interesting! I do usually prefer using a query builder or raw SQL over an ORM, and will definitely check this one
Mikro ORM [1] is the new hot sauce over TypeORM and it is fantastic.
[1] https://mikro-orm.io/
[1] https://mikro-orm.io/
I have been using it for a new project and it really is awesome. I can't imagine going back to an ORM or another query builder now.
Been using it as well on a side project together with nexus and nexus-prisma and it's really a joy to work with.
Same we've been using Graphcool/Prisma 1 for 2 years. Has been single handedly the biggest reason for our speed of development. We absolutely love the generated types and automatic introspection, everything is just documented automatically, it's truly revolutionary.
Looks cool! Is there a business model around prisma?
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!
More info here: https://www.prisma.io/docs/more/faq#how-much-does-prisma-20-...
More info here: https://www.prisma.io/docs/more/faq#how-much-does-prisma-20-...
Hi there, I'm a prisma 1 user and am wondering if there is thorough docs on how to transition over to prisma 2.
Also what breaking changes or not-yet-implemented features of prisma1 should I be aware of.
----
Edit: I see there's a "I currently use Prisma 1, what should I do?" section. Any other info would be greatly appreciated.
Also what breaking changes or not-yet-implemented features of prisma1 should I be aware of.
----
Edit: I see there's a "I currently use Prisma 1, what should I do?" section. Any other info would be greatly appreciated.
Hey! We will provide upgrade guides and dedicated tooling [1] in the next couple of weeks to ensure a smooth transition for current Prisma 1 users!
You can find more context on isprisma2ready.com.
[1] https://github.com/prisma/prisma/issues/1937
You can find more context on isprisma2ready.com.
[1] https://github.com/prisma/prisma/issues/1937
I don’t know why this is not getting more up votes it looks pretty cool.
At first it may seem like yet another attempt to make database access easy while really making it more complex and harder to maintain.
I haven’t tried this yet, but after reading a couple pages it looks more interesting than that. For example the fact that it relies on typescript knowledge which is already widespread, and the fact that it doesn’t require any server side technology to be installed is a huge advantage.
I’m not sure how it feels in practice, if anyone has experience with it please chime in.
At first it may seem like yet another attempt to make database access easy while really making it more complex and harder to maintain.
I haven’t tried this yet, but after reading a couple pages it looks more interesting than that. For example the fact that it relies on typescript knowledge which is already widespread, and the fact that it doesn’t require any server side technology to be installed is a huge advantage.
I’m not sure how it feels in practice, if anyone has experience with it please chime in.
One headline is:
Focus on your data – not on complex SQL queries
Looks like just another SQL DSL trying to make you not learn SQL. TS's structural typing and plain SQL can get you far into a simpler/robust system IMO.
Also, the "introspection" part of Prisma seems very crippled, Postgres has so many useful features for writing application code that it seems wasteful to just treat it as dumb data store.
Focus on your data – not on complex SQL queries
Looks like just another SQL DSL trying to make you not learn SQL. TS's structural typing and plain SQL can get you far into a simpler/robust system IMO.
Also, the "introspection" part of Prisma seems very crippled, Postgres has so many useful features for writing application code that it seems wasteful to just treat it as dumb data store.
I find the process of writing database access functions annoying, and for the most part, arbitrary and repetitive. ORM functionality that bakes types/accessors, migrations, graphQL, and even infrastructure into your codebase is where it’s at. The fact that you are writing your models once and automatically exposing them as types in any project’s language is a huge value. I don’t need the same language everywhere, but I want types that plug together without hassle.
Next generation “serverless” databases will fully abstract object mapping away. It’s tedious and arbitrary. Even indexing is relatively easy to automate. I am incredibly excited for what Apple is brewing up right now for developers.
Next generation “serverless” databases will fully abstract object mapping away. It’s tedious and arbitrary. Even indexing is relatively easy to automate. I am incredibly excited for what Apple is brewing up right now for developers.
Is Apple working on some sort of serverless/Firebase type thing?
I think they're referring to this: https://developer.apple.com/icloud/cloudkit/
It kind of flew under the radar, because it's not super clear how to use it from the landing page.
It kind of flew under the radar, because it's not super clear how to use it from the landing page.
CloudKit, edge, etc
What is apple brewing?
Composability and encapsulation are both somewhat lacking in SQL and there are valid reasons to want to write queries in a different DSL that can be compiled to SQL.
Just stop the anti-ORM bs. Most applications need simple select queries, and often want to walk the obejct / relation graph. Prism looks awesome, and has great TS support. If you want to concatenate sql for each frikking query, be my guest. I have better things to do with my time, such as responding to this kind of stuff.
For "small" and "large" queries, just use the ORM. For "complex" queries, just use SQL.
For "small" and "large" queries, just use the ORM. For "complex" queries, just use SQL.
SQL isn't type-safe, so Prisma has that over it if nothing else. There's also a lot to be said for the difficulty in composing efficient SQL queries. If this tool can do that (I would be surprised) it would be a significant advancement (yes, this would be "making you not learn SQL" in the same way C makes you "not learn assembly").
Hmm, in what sense is SQL not type safe where this would be type safe, though? You could still use out of date client code connected to a DB that has had its schema change, no?
The DB and the code are not packaged together so is there even such a thing as compile time type safety?
The DB and the code are not packaged together so is there even such a thing as compile time type safety?
Something like this would make sure that all queries are correct per some expected schema and processes keep the expected and live schemas in sync. Such a process might be "database migrations run in the CD pipeline and nothing else changes the database". Of course there are edge cases here and there (someone will eventually need to log into a production database), but these processes go a long way toward reducing risk.
SQL is as type-safe as the DB engine allows it to be. PostgreSQL is type-safe. Extracting these types and making them available and usable in your lang-of-choice at compile time is a different problem though.
Yes, when we talk about type safety, we generally mean "compile time" type safety. Python is also "type safe" at runtime (which is to say, "it's strongly typed"), but we don't conventionally consider Python to be type-safe.
Well, all I am saying is that PostgreSQL provides you with compile-time type-safety when your write your queries.
Bringing this type information at "compile-time" into your language of choice where you embed your queries can also be done but is a harder problem. There is good progress in that sphere but it is still in it is infancy.
The GraphQL eco-system for example, has this figured out using code generators. A similar thing can be done with DBs.
Bringing this type information at "compile-time" into your language of choice where you embed your queries can also be done but is a harder problem. There is good progress in that sphere but it is still in it is infancy.
The GraphQL eco-system for example, has this figured out using code generators. A similar thing can be done with DBs.
python is type-safe if you use python3 and avoid the dynamic parts of the language using a linter.
Since it does no checking of the annotations at runtime: I don't really think this is accurate. This prints `5` for instance: https://repl.it/repls/DarkorchidFailingComputationalscience
def do(s: int) -> str:
return 5
print(do("123"))
That depends on who you generally talk with. Dynamic typing/static typing are orthogonal to eg weak/strong typing and other type system features, that's estabilished terminology.
Nothing in your post contradicts mine, but you're using a contradictory tone, so I'm confused. Dynamic/static typing are indeed orthogonal to weak/strong typing; however, the OP seemed to be arguing that "SQL is typesafe because it is statically checked at runtime/JIT-compile-time" which is almost exactly the definition of "strong typing" and not generally what we mean by "type safe" (the latter typically refers to statically typed).
I think you misunderstood my point. You mentioned that "SQL isn't type-safe", which is NOT true. Any decent RDB engine allows to perform typechecking and validation of your query without executing it. This means that SQL is typesafe at compile time.
[deleted]
Fair enough. This is a small consolation for practitioners, especially since much SQL is often composed dynamically, and the engine can't tell you about where the composition went wrong (unlike Rust, TS, etc). Maybe if SQL had its own hygienic macro language, but I'm not sure how that would compare to libraries like Prisma.
> Postgres has so many useful features for writing application code
Except versioning, maintainability, testability, source control, migration, or just about 80% of what an application developers expects from the thing that runs their code.
I mean, I really really love the idea of stored procedures and triggers, it's so much more elegant than putting all the code in some Node app and just doing read-modify-write cycles into the DB, but until DBs get their ass together wrt being a properly useable platform to run code on, it's not gonna happen.
Except versioning, maintainability, testability, source control, migration, or just about 80% of what an application developers expects from the thing that runs their code.
I mean, I really really love the idea of stored procedures and triggers, it's so much more elegant than putting all the code in some Node app and just doing read-modify-write cycles into the DB, but until DBs get their ass together wrt being a properly useable platform to run code on, it's not gonna happen.
You can use things like Flyway or other tools that track schemas and migrations in source control quite easily.
I have been rewriting a big application with it, I would say its getting there but some features are still lacking and you start to hit them when you do more advanced stuff (long-lived transactions, aggregation, etc.). But the team is working very fast and I am super confident we will have everything by GA (most of the issues are tracked). For example we didn't have access to foreign keys last week and they added that in like 3 days. It's a huge step forward in terms of code quality is you don't like ORM like me, but you also hate not having typing when using query builders/raw SQL.
Tom Preston-Werner chose to include Prisma 2 in his new RedwoodJS project and it's been a pleasure to work with.
I'm very curious. Can you pleas share some specifics.
Looks nice, have not seen this. I'm more and more inclined to take a JAMstack approach with new projects, so RedwoodJS looks very interesting.
I keep seeing Prisma pop it's head up every now and then and I've been curious. I looks pretty nice, maybe I'll start a toy project in Redwood and try them both out!
I keep seeing Prisma pop it's head up every now and then and I've been curious. I looks pretty nice, maybe I'll start a toy project in Redwood and try them both out!
>> Tom Preston-Werner chose to include Prisma 2 in his new RedwoodJS project
Sorry to say, above comment is mostly cringe worthy! Having tried Redwoodjs, I should say at the moment Nextjs offers everything better.
Sorry to say, above comment is mostly cringe worthy! Having tried Redwoodjs, I should say at the moment Nextjs offers everything better.
Are you really comparing a project in alpha to a project that has many years development?
Will SQL Server databases be supported at some point?
We're indeed planning to broaden the support for various databases in the future (e.g. already looking into MongoDB and FaunaDB).
If you have a specific DB in mind that you'd like to see supported, please open a feature request here: https://github.com/prisma/prisma/issues/new?assignees=&label...
If you have a specific DB in mind that you'd like to see supported, please open a feature request here: https://github.com/prisma/prisma/issues/new?assignees=&label...
Good to hear. Curious why Fauna is being looked into by your team, since it appears to be a much newer database (and also not open sourced AFAIK)?
Mongo makes sense given its obvious popularity.
Does this work with pnpm since node_modules/@prisma/client changes based on the project it's in?
It works fine with pnpm. The client package has a postinstall hook that generates the client after you install it.
We started using Prisma 1 for our project and ran really fast into missing features that are really missing for a complete product.
But with a few workarounds it was possible to make it work and is quite nice to use.
Example of missing features:
Primary key as a combination of two relational models: https://github.com/prisma/prisma1/issues/3553
Database Constraints https://github.com/prisma/prisma1/issues/728
Cascading Deletes https://github.com/prisma/prisma1/issues/1262
Upsert https://github.com/prisma/prisma1/issues/2194
On delete restrict https://github.com/prisma/prisma1/issues/2701
Mutation CreateOrConnect https://github.com/prisma/prisma1/issues/3724
Improving performance with Indexes https://github.com/prisma/prisma1/issues/1300
Multiple field unique constraint https://github.com/prisma/prisma1/issues/171
Interface types https://github.com/prisma/prisma1/issues/83
Embedded Types https://github.com/prisma/prisma1/issues/2836
Declarative support for multi-field unique constraints https://github.com/prisma/prisma1/issues/1237
Support union types https://github.com/prisma/prisma1/issues/165
Transactions for multiple mutations https://github.com/prisma/prisma1/issues/74
But with a few workarounds it was possible to make it work and is quite nice to use.
Example of missing features:
Primary key as a combination of two relational models: https://github.com/prisma/prisma1/issues/3553
Database Constraints https://github.com/prisma/prisma1/issues/728
Cascading Deletes https://github.com/prisma/prisma1/issues/1262
Upsert https://github.com/prisma/prisma1/issues/2194
On delete restrict https://github.com/prisma/prisma1/issues/2701
Mutation CreateOrConnect https://github.com/prisma/prisma1/issues/3724
Improving performance with Indexes https://github.com/prisma/prisma1/issues/1300
Multiple field unique constraint https://github.com/prisma/prisma1/issues/171
Interface types https://github.com/prisma/prisma1/issues/83
Embedded Types https://github.com/prisma/prisma1/issues/2836
Declarative support for multi-field unique constraints https://github.com/prisma/prisma1/issues/1237
Support union types https://github.com/prisma/prisma1/issues/165
Transactions for multiple mutations https://github.com/prisma/prisma1/issues/74
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 :)
So is that some sort of "ActiveRecord" for Javascript? It looks pretty darn cool.
How does it differ from Hasura?
It has a lot more features (and is more complicated).
Prisma and Hasura are very different!
Prisma is a database toolkit that's used by application developers to develop server-side applications in Node.js and TypeScript (e.g. REST APIs, microservices, gRPC calls, GraphQL APIs, ..., anything that talks to a database). The main tool Prisma Client is a query builder that's used to programmatically send queries to a database from Node.js/TS.
Hasura is a "GraphQL-as-a-Service" provider that generates a GraphQL API for your database. This GraphQL API is typically accessed by frontend developers. That setup can be great when your application doesn't require a lot of business logic and the CRUD capabilities that are exposed in the GraphQL API fit your needs (though I believe you can add business logic in Hasura by integrating serverless functions).
With Prisma, you're still in full control of your own backend application and can choose whatever tech stack you like for developing it (as long as it's Node.js-based, though Prisma Client will be in available in more languages the future)!
By the way, we also love GraphQL. We're currently brewing a new "GraphQL application framework" that can be used on top of Prisma. That way it will be possible to auto-generate resolvers for Prisma models to reduce the boilerplate you need to write, while still keeping the full control of your GraphQL schema.
You can learn more about this here: https://www.nexusjs.org/#/
Prisma is a database toolkit that's used by application developers to develop server-side applications in Node.js and TypeScript (e.g. REST APIs, microservices, gRPC calls, GraphQL APIs, ..., anything that talks to a database). The main tool Prisma Client is a query builder that's used to programmatically send queries to a database from Node.js/TS.
Hasura is a "GraphQL-as-a-Service" provider that generates a GraphQL API for your database. This GraphQL API is typically accessed by frontend developers. That setup can be great when your application doesn't require a lot of business logic and the CRUD capabilities that are exposed in the GraphQL API fit your needs (though I believe you can add business logic in Hasura by integrating serverless functions).
With Prisma, you're still in full control of your own backend application and can choose whatever tech stack you like for developing it (as long as it's Node.js-based, though Prisma Client will be in available in more languages the future)!
By the way, we also love GraphQL. We're currently brewing a new "GraphQL application framework" that can be used on top of Prisma. That way it will be possible to auto-generate resolvers for Prisma models to reduce the boilerplate you need to write, while still keeping the full control of your GraphQL schema.
You can learn more about this here: https://www.nexusjs.org/#/
I want to point out a defining characteristic between Hasura and Prisma:
While Hasura does work to auto-generate a GraphQL API from an existing database, it also has a web console that lets you build your database models and relationships, plus permission logic and authorization point-and-click.
Custom business-logic outside of the CRUD it generates is done by writing HTTP endpoints that you can wrap as "Actions", which it generates GraphQL types and resolvers for as part of it's schema. IE, you will want to define an API endpoint for login/signup, and declare these as "Actions", which you can then query from Hasura's schema.
An SDK/toolkit can be auto-generated from the GraphQL schema Hasura produces using graphql-code-generator, giving you strongly-typed query/mutation/subscription components in your desired frontend framework (IE React/Vue/Angular + Apollo/urql etc.)
Scheduled tasks/cronjob functionality is under development as well.
Prisma gives you a "finer grained" set of tools to "build" an application with, where Hasura kind of just hands you the whole thing (though in an opinionated fashion).
While Hasura does work to auto-generate a GraphQL API from an existing database, it also has a web console that lets you build your database models and relationships, plus permission logic and authorization point-and-click.
Custom business-logic outside of the CRUD it generates is done by writing HTTP endpoints that you can wrap as "Actions", which it generates GraphQL types and resolvers for as part of it's schema. IE, you will want to define an API endpoint for login/signup, and declare these as "Actions", which you can then query from Hasura's schema.
An SDK/toolkit can be auto-generated from the GraphQL schema Hasura produces using graphql-code-generator, giving you strongly-typed query/mutation/subscription components in your desired frontend framework (IE React/Vue/Angular + Apollo/urql etc.)
Scheduled tasks/cronjob functionality is under development as well.
Prisma gives you a "finer grained" set of tools to "build" an application with, where Hasura kind of just hands you the whole thing (though in an opinionated fashion).
Hasura can run as a Backend as a Service, ie standalone with a direct connection to your database and nothing else. For custom queries you can use Hasura Actions.
Prisma and others like Apollo server are libraries you need to add to your Node app, ie not standalone. They give you more customization because you control the entire server and what functions to run.
The difference is just in how custom you want it and how much setup you don't want to do.
Prisma and others like Apollo server are libraries you need to add to your Node app, ie not standalone. They give you more customization because you control the entire server and what functions to run.
The difference is just in how custom you want it and how much setup you don't want to do.
Is real-time subscriptions on the roadmap? It's the most killer feature of Hasura and Postgraphile IMO.
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!
We have an open feature request for that here: https://github.com/prisma/prisma/issues/298
[1] https://www.nexusjs.org/#/
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!
We have an open feature request for that here: https://github.com/prisma/prisma/issues/298
[1] https://www.nexusjs.org/#/
You can put an apollo server on top of prisma and then you can do the subscriptions yourself with a pubsub (redis in our case)
Was really excited about this until I got to "smart node module". Isn't changing the contents of a package in node_modules going to break any kind of caching, de-duplicating etc? In my current project we install node_module` ahead of time and bake it into a docker image, it is quite common.
Is there any other framework or library using these "smart" node_modules ? I never noticed.
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.
Was there consideration of using something like schemats[1] and allowing users to specify where they want to store the types for their schema? Storing them in `node_modules` is extremely unidiomatic and probably rules this library out for me even though it's otherwise attractive at first glance.
[1]: https://github.com/SweetIQ/schemats
[1]: https://github.com/SweetIQ/schemats
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.
[4] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
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.
[4] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
That sounds nice. Your link 404s tho.
Edit: it did at first, now it's loading. I've seen other 404s just clicking around the docs. It's possible you've got some CDN caching issues?
Edit: it did at first, now it's loading. I've seen other 404s just clicking around the docs. It's possible you've got some CDN caching issues?
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 nikolas! Svelte's Sapper generates its own @sapper modules I believe. https://github.com/sveltejs/sapper/
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.
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[2] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[3] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[4] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
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.
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[2] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[3] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
[4] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
Having the option to generate it elsewhere is great, because it does break some pretty big integrity invariants that are assumed by various tools. node_modules shouldn't be changing, specially when there's lockfiles being used.
This is such. A. Stupid. Decision. Indeed.
For example, we use yarn pnp in our codebase so I have absolutely no hope that it will ever work with Prisma 2.
“Don’t try to be smart” is a very useful mantra for programmers, but Prisma seems to ignore this.
But hey I don’t want to use it anyway because what I want is a graphql endpoint not an ORM. We used Prisma 1 and now moved on to graphile.
For example, we use yarn pnp in our codebase so I have absolutely no hope that it will ever work with Prisma 2.
“Don’t try to be smart” is a very useful mantra for programmers, but Prisma seems to ignore this.
But hey I don’t want to use it anyway because what I want is a graphql endpoint not an ORM. We used Prisma 1 and now moved on to graphile.
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".
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [2] https://twitter.com/FredKSchott/status/1245053210852618246
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".
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr... [2] https://twitter.com/FredKSchott/status/1245053210852618246
Edit: please read nikolasburk's answer below which makes a lot of sense. The docs weren't an attempted attack on all ORMs but rather a description of problems with certain Javascript ORMs.
My original post:
This looked interesting at first but this reads like someone either don't know a thing about JPA and Entity Framework or are deliberately misrepresenting them:
> ORMs are libraries that map tables in your database to classes in your programming language. Prisma on the other hand is an auto-generated query builder that exposes queries which are tailored to your models. All Prisma Client queries return plain old JavaScript objects.
Yep, tables maps to classes, but guess what gets returned?
Plain Old Java (or CLR) Objects. And guess what: Thanks to those languages well thought out design and extensive metaprogramming abilities this can all be done without making up a new language also.
This is probably the harshest I've been here on HN, but smearing good solutions really doesn't sit well with me.
My original post:
This looked interesting at first but this reads like someone either don't know a thing about JPA and Entity Framework or are deliberately misrepresenting them:
> ORMs are libraries that map tables in your database to classes in your programming language. Prisma on the other hand is an auto-generated query builder that exposes queries which are tailored to your models. All Prisma Client queries return plain old JavaScript objects.
Yep, tables maps to classes, but guess what gets returned?
Plain Old Java (or CLR) Objects. And guess what: Thanks to those languages well thought out design and extensive metaprogramming abilities this can all be done without making up a new language also.
This is probably the harshest I've been here on HN, but smearing good solutions really doesn't sit well with me.
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).
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).
Ok, thanks for replying. I've been busily trying to reword my post since talking down to people who stand up and make things really isn't my thing either.
I guess your explanation here makes a lot of sense - I don't know much about Javascript ORMs.
I guess your explanation here makes a lot of sense - I don't know much about Javascript ORMs.
I don't really understand the claim you're making here--you have to go out of your way in TypeORM to get ActiveRecord objects instead of plain JavaScript objects. The happy path is pretty firmly in data-mapper territory; as an example, for all the shade I will happily fling NestJS's way they just hand you a Repository and tell you to get on with your day.
There's also stuff like Objection.js (which works well in TypeScript), too.
I don't dislike Prisma, but the framing is really strange to me.
There's also stuff like Objection.js (which works well in TypeScript), too.
I don't dislike Prisma, but the framing is really strange to me.
Could be off-topic for this thread... but what shade would you like to throw NestJS's way? Or do you have a write-up somewhere else, by chance?
- I think it comprehensively misunderstands and mis-implements a lot of things that are important. Their “microservices” boondoggle is a whatever RPC mechanism that has no real reason to exist, their CQRS library expects the world to be a single node, their OpenAPI library is vestigial and completely separates the generation of documentation from actually validating inputs. Most of the things outside of core are rotated about 45 degrees away from where you’d expect with a holistic understanding of a web application. Stuff built by somebody who heard of a problem, not felt a problem.
- I think that the core team is bad at and refuses to improve at communicating with its community via roadmaps. Huge changes just appear, including literally breaking changes within a given major release, with little to no warning.
- I think they don’t respect what community they do have, building completely new, blessed-by-the-core-team libraries that step on existing open-source solutions in the NestJS ecosystem mostly just so the package can say “@nestjs/“ at the front of it. (Top of mind example is “@nestjs/schedule”, which is a worse take on “nest-schedule.") There isn't much personal incentive to build community tooling if the core team will swoop in and go "mine now!" without so much as a prior-work credit and it's disrespectful besides.
- They continue to build their own tooling that steps on the accepted norms and systems in the Node community. The NestJS CLI now incorporates "monorepos" that aren't Lerna or Yarn ones; they're also pushing developers to use it as their primary way of building applications, rather than invoking tsc, with the dangly carrot of "we'll write plugins for it [rather than using one of the existing ways to better handle extended compilation]". It feels like a lock-in play for future monetization (there's open rumors that Kamil is very focused on monetization, which--you do you, but as Rails and Django and even Spring showed us this stuff seems to really work better if you care about it existing to exist, and you make money off of using it) and the lack of community roadmap makes assuaging those concerns very much not a priority of the core team.
I was a big booster of NestJS a year ago and I’ve written a bunch of modules for it. I was even a personal donor to the project's Open Collective, it's the only project I've ever done that for. But I do not use NestJS for new projects because I have no confidence in the design or the leadership there and I don’t think it’s a wise use of my time anymore.
- I think that the core team is bad at and refuses to improve at communicating with its community via roadmaps. Huge changes just appear, including literally breaking changes within a given major release, with little to no warning.
- I think they don’t respect what community they do have, building completely new, blessed-by-the-core-team libraries that step on existing open-source solutions in the NestJS ecosystem mostly just so the package can say “@nestjs/“ at the front of it. (Top of mind example is “@nestjs/schedule”, which is a worse take on “nest-schedule.") There isn't much personal incentive to build community tooling if the core team will swoop in and go "mine now!" without so much as a prior-work credit and it's disrespectful besides.
- They continue to build their own tooling that steps on the accepted norms and systems in the Node community. The NestJS CLI now incorporates "monorepos" that aren't Lerna or Yarn ones; they're also pushing developers to use it as their primary way of building applications, rather than invoking tsc, with the dangly carrot of "we'll write plugins for it [rather than using one of the existing ways to better handle extended compilation]". It feels like a lock-in play for future monetization (there's open rumors that Kamil is very focused on monetization, which--you do you, but as Rails and Django and even Spring showed us this stuff seems to really work better if you care about it existing to exist, and you make money off of using it) and the lack of community roadmap makes assuaging those concerns very much not a priority of the core team.
I was a big booster of NestJS a year ago and I’ve written a bunch of modules for it. I was even a personal donor to the project's Open Collective, it's the only project I've ever done that for. But I do not use NestJS for new projects because I have no confidence in the design or the leadership there and I don’t think it’s a wise use of my time anymore.
What are you using now for your new projects instead of nestjs?
I'm writing a framework atop Fastify at the moment. My intention is to address a number of deep-seated technical problems I see with NestJS and present a holistic view of an application, rather than a web app, that can be used to more clearly structure and maintain my projects. I don't intend to monetize it, so I don't feel compelled to work outside of the normal NodeJS ecosystem and if there's any interest I intend to build a binding steering committee rather than run the risk of having a non-communicative "B"DFL.
Those, who prefer a more old-school approach, may find PgTyped [1] interesting: you write SQL and you have typings in TypeScript. Still very alpha, but promising.
I'm working on integrating PgTyped into Huncwot [2]
[1]: https://github.com/adelsz/pgtyped [2]: https://github.com/huncwotjs/huncwot
I'm working on integrating PgTyped into Huncwot [2]
[1]: https://github.com/adelsz/pgtyped [2]: https://github.com/huncwotjs/huncwot
Looks very interesting.
At the moment we're using a Node.js + Postgres + Sequelize ORM [1] + Express setup in production and are very happy. All lot of features and very robust setup.
Any production ready experience with Prisma?
[1]: https://sequelize.org/v5/
Any production ready experience with Prisma?
[1]: https://sequelize.org/v5/
I LOVE massivejs[1], a query builder type library for Postgres in nodejs. Is prisma2 like massivejs but for typescript?
If someone’s tried both, would love a quick comparison :)
[1] https://massivejs.org/
If someone’s tried both, would love a quick comparison :)
[1] https://massivejs.org/
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! :)
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! :)
That's why I love HN! One published new solution and a whole tree of wonderful comments about related tech.
The fact that the returned objects are plain old javascript objects (POJOs) that's nice.
The smart module bit, it's a bit scary.
basically all I want is a lightweight layer that exposes a promise api to deal with different databases in a uniform manner.
1) sync to schema.json (this json file contains info of all tables, their columns, indices and foreign keys). I can sync to db or from db. This lets me have my state of schema committed to git, and easily move from dev -> staging -> prod. Django migrations are a giant pain in the ass. Don't do smart fancy node modules either.
2) autogenerated typescript types, this are nice. But again don't do fancy node modules, have the typescript types committable to git repo. It makes it easy to diff and bisect when things fo awry.
3) Super light weight Object -> sql. Access foreign relationships as promises (always). Make it very easy to debug the generated sql for perf reasons. Django does some bits well but it's insanely slow at times. Doing things with raw sql should be just as fast as using a library.
The smart module bit, it's a bit scary.
basically all I want is a lightweight layer that exposes a promise api to deal with different databases in a uniform manner.
1) sync to schema.json (this json file contains info of all tables, their columns, indices and foreign keys). I can sync to db or from db. This lets me have my state of schema committed to git, and easily move from dev -> staging -> prod. Django migrations are a giant pain in the ass. Don't do smart fancy node modules either.
2) autogenerated typescript types, this are nice. But again don't do fancy node modules, have the typescript types committable to git repo. It makes it easy to diff and bisect when things fo awry.
3) Super light weight Object -> sql. Access foreign relationships as promises (always). Make it very easy to debug the generated sql for perf reasons. Django does some bits well but it's insanely slow at times. Doing things with raw sql should be just as fast as using a library.
Prisma Client is generated into node_modules by default (because that's the most familiar thing for JS/TS devs), but you can specify any target location you like for it: https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
getting a `Not Found`
This seems to be solving mostly the same problem as the following libraries:
[1] https://github.com/phiresky/ts-typed-sql [2] https://github.com/Ff00ff/mammoth [3] https://github.com/AnyhowStep/tsql [4] https://github.com/travigd/vulcyn
A query in one of those looks like the following:
Prisma solves the problem by generating code, while all of these do it completely in type-level within typescript. Prisma also seems to introduce its own query language, while the above linked libraries stay closer to SQL.
[1] was written by a friend of mine and I'm using it in production to great success. I wouldn't recommend it though because it has repeatedly broken with new TypeScript updates since it uses very complex type structures and the dev has basically given up on it due to the complexity.
[2] is probably the most production-ready, though it has some design choices I'm not sure about.
[3] is the most well-designed, and can handle complex scenarios (including differentiating between join types etc). But it's incomplete so far.
[4] I have not used.
Pure type-level has the advantage of not adding a compile-step and keeping everything in a tool you already know. But all of the above have the disadvantage that the resulting type structures are very complex - most TS devs would have a hard time understanding the internals of the libraries and the resulting type errors can be unreadable. They can also cause the TS compiler to slow down significantly (in the past [1] had exponential compile time when adding a new column, though this has been fixed).
Also, since the TS compiler uses heuristics in multiple places and the type system is not sound, Microsoft has introduced regressions that have broken [1] in every other release.
[1] https://github.com/phiresky/ts-typed-sql [2] https://github.com/Ff00ff/mammoth [3] https://github.com/AnyhowStep/tsql [4] https://github.com/travigd/vulcyn
A query in one of those looks like the following:
const rows = await select(list.id, list.createdAt)
.from(list)
.where(list.createdAt.gt(now().minus(`2 days`)).or(list.value.eq(0)))
.limit(10);
Prisma solves the problem by generating code, while all of these do it completely in type-level within typescript. Prisma also seems to introduce its own query language, while the above linked libraries stay closer to SQL.
[1] was written by a friend of mine and I'm using it in production to great success. I wouldn't recommend it though because it has repeatedly broken with new TypeScript updates since it uses very complex type structures and the dev has basically given up on it due to the complexity.
[2] is probably the most production-ready, though it has some design choices I'm not sure about.
[3] is the most well-designed, and can handle complex scenarios (including differentiating between join types etc). But it's incomplete so far.
[4] I have not used.
Pure type-level has the advantage of not adding a compile-step and keeping everything in a tool you already know. But all of the above have the disadvantage that the resulting type structures are very complex - most TS devs would have a hard time understanding the internals of the libraries and the resulting type errors can be unreadable. They can also cause the TS compiler to slow down significantly (in the past [1] had exponential compile time when adding a new column, though this has been fixed).
Also, since the TS compiler uses heuristics in multiple places and the type system is not sound, Microsoft has introduced regressions that have broken [1] in every other release.
This doesn't work well when you have lots of queries that require a self-join.
Get me a friend of a friend of a friend who joined 2 days ago.
https://github.com/facebookexperimental/fquery/blob/master/t...
Get me a friend of a friend of a friend who joined 2 days ago.
https://github.com/facebookexperimental/fquery/blob/master/t...
Thanks for sharing these projects. So far I only knew tsql.
I'm in the avoid code generation camp as well as typically my build processes are complex enough and don't need another step.
But I am not quite satisfied by the existing query generators. Also after having read https://github.com/jawj/mostly-ormless/blob/master/README.md I wanted to put Postgres' `json_agg` function into use as it looks like it is simplifying a lot of the nested objects stuff one serves over REST APIs.
So I designed my own https://github.com/hoeck/typesafe-query-builder - with special support for `json_agg` and `json_build_object`. Its working already in production and for me, the dev UX is unprecedented in working with database code. Typechecks and autocompletions really boost it. But to be honest, I'm a bit worried about Typescript compiler bugs and compilation times when the project grows.
I'm in the avoid code generation camp as well as typically my build processes are complex enough and don't need another step.
But I am not quite satisfied by the existing query generators. Also after having read https://github.com/jawj/mostly-ormless/blob/master/README.md I wanted to put Postgres' `json_agg` function into use as it looks like it is simplifying a lot of the nested objects stuff one serves over REST APIs.
So I designed my own https://github.com/hoeck/typesafe-query-builder - with special support for `json_agg` and `json_build_object`. Its working already in production and for me, the dev UX is unprecedented in working with database code. Typechecks and autocompletions really boost it. But to be honest, I'm a bit worried about Typescript compiler bugs and compilation times when the project grows.
I was really excited when Prisma1 came out. It would be understatement to mention that Prisma1 was way overpromised and nothing ever materialised.
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]
Also Prisma2 has half of the features at 'No / Not yet' supported state - https://www.prisma.io/docs/reference/database-connectors/dat...
Well makes me wonder what's wrong with TypeORM which supports 8 different databases with full feature support and migrations that work!
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
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]
Also Prisma2 has half of the features at 'No / Not yet' supported state - https://www.prisma.io/docs/reference/database-connectors/dat...
Well makes me wonder what's wrong with TypeORM which supports 8 different databases with full feature support and migrations that work!
[1] https://www.prisma.io/docs/reference/tools-and-interfaces/pr...
Data Validation
Cascading delete
Cascading update
Renaming existing table
Renaming existing column> 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).
[1] https://www.prisma.io/docs/guides/database-workflows/cascadi...
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).
[1] https://www.prisma.io/docs/guides/database-workflows/cascadi...
I experienced many kinds of problems with TypeORM, including data corruption and lost. Before using it in a project I strongly suggest taking a look around its issues or at least reading the issue about its future [0].
On the other side my experience with Prisma 2 so far has been excellent and I found a very good community around it.
[0] https://github.com/typeorm/typeorm/issues/3267
On the other side my experience with Prisma 2 so far has been excellent and I found a very good community around it.
[0] https://github.com/typeorm/typeorm/issues/3267
>> including data corruption and lost
Im using TypeORM and happy to learn if it is so. Can you please show any relevant issues for it ?
It would be interesting to understand how data corruption and lost happens at ORM level!
The gist of this conversation is - passionate open source devs outdo many folds in their work yet fail to monetise their work. And a VC backed company here has little to show for apart from they've managed to trend in HN!
Im using TypeORM and happy to learn if it is so. Can you please show any relevant issues for it ?
It would be interesting to understand how data corruption and lost happens at ORM level!
The gist of this conversation is - passionate open source devs outdo many folds in their work yet fail to monetise their work. And a VC backed company here has little to show for apart from they've managed to trend in HN!
https://github.com/typeorm/typeorm/issues/3636 this is last one I encountered before abandoning TypeORM.
To be fair sync feature is marked as unsafe to use in production in documentation.
The issue title mentions the sync feature but the same happened with migrations and I don't want code randomly dropping data from my database even if it is in a development environment anyway. But that is not the point because no one would run automatic code like this on production data without some kind safety net. The point I was trying to make is "listing features as non beta doesn't make them stable". As far as I am concerned the alpha preview of Prisma 2 has been far more stable than every other version of TypeORM I had to work with.
After working with TypeORM in a quite few projects I can tell that there're a lot of things that are wrong with it. And TypeORM absolutely doesn't provide "full feature support" for all 8 databases. Even some basic things are missing, like joins on delete sql queries in query builder. Simple 'set' mysql datatype support was missing and I had to add it myself. When it comes to mapping and data modeling, things are OK most of the time but it breaks when it comes to somewhat non-basic stuff like STI. Don't get me started on bugs. Any reasonable alternatives and orm developments are welcome and Prisma2 doesn't take away anything, it's a free software.
TypeORM seems wonderful for basic stuff, but also in dire need of maintainers/contributors, at least based on its GitHub issues and docs [0] to get that last 20% (that takes just as much time as the first 80%).
https://github.com/typeorm/typeorm/blob/master/docs/query-ru...
https://github.com/typeorm/typeorm/blob/master/docs/query-ru...
It's actually really good but I don't get the feel of wonder after all those years together anymore :) Huge db and feature scope definitely keep it away from any particular completeness despite size and age of the project. Hope to see something more focused @next.
This looks great and should surely cover most of the CRUD needs of simpler apps and hopefully even more.
On the other hand, in my experience such complicated abstractions eventually leak, especially due to the complicated nature of the relational model and modern SQL.
For developers not keen on adding a thick indirection layer between the app and the DB, I have been trying to make raw SQL easier and more reliable to use directly in TS with PgTyped[1].
In general, I think most people are more than glad to use raw SQL solution instead of a mapper as long as it has:
1) Realtime parameter/result type inference in their language of choice.
2) Has autocomplete and validation in their IDE
3) Is composable, allowing to join queries/sub-queries..
So far I have been able to implement SQL-in-TS type inference in PgTyped[1] with autocomplete and validation on the way.
[1]: https://github.com/adelsz/pgtyped
For developers not keen on adding a thick indirection layer between the app and the DB, I have been trying to make raw SQL easier and more reliable to use directly in TS with PgTyped[1].
In general, I think most people are more than glad to use raw SQL solution instead of a mapper as long as it has:
1) Realtime parameter/result type inference in their language of choice.
2) Has autocomplete and validation in their IDE
3) Is composable, allowing to join queries/sub-queries..
So far I have been able to implement SQL-in-TS type inference in PgTyped[1] with autocomplete and validation on the way.
[1]: https://github.com/adelsz/pgtyped
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 :)
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 :)
I’ve been using Prisma in development and highly recommend it. There’s nothing like it out there!
Why generate types from a query when you can write a schema for your objects and then write queries where types can be inferred based on object types and query constructs?
Some ideas from a recently open sourced project:
https://github.com/facebookexperimental/fquery/blob/master/t...
Some ideas from a recently open sourced project:
https://github.com/facebookexperimental/fquery/blob/master/t...
It's alright isn't it to get something done fast, until this huge amount of code that you will never understand bites you in the ass.
I'm secretly rewriting an API written in Prisma 1 into something lower level that actually allows me to write database queries, optimise what is going on, look into the simple underlying abstractions if things go wrong and essentially produce something I can reason about without just hoping nothing goes wrong under the hood.
Apollo codegen is what you want if you'd like your Typescript frontend to be consuming the API in a typesafe way.
I'm secretly rewriting an API written in Prisma 1 into something lower level that actually allows me to write database queries, optimise what is going on, look into the simple underlying abstractions if things go wrong and essentially produce something I can reason about without just hoping nothing goes wrong under the hood.
Apollo codegen is what you want if you'd like your Typescript frontend to be consuming the API in a typesafe way.
You might want to have a look at Postgraphile. It is nice
I wish I was not stuck on Ms SQL server. The JS ecosystem tends to ignore it or treat it as a second class citizen. Would love to check this out otherwise.
Makes sense, non-type-safe language, we can push type safety guarantees to the persistence layer by coupling the domain models to the type-safe data models.
Why on earth did Prisma take the choice to move away from a brilliant automatic GraphQL backend as a service to some kind of weird ORM?
Prisma became relevant during their Prisma 1 time, it was one of the first solutions to automatically generate GraphQL endpoints from DB schemas. It only had to keep going this way to lead the whole market. But they chose not too, and competing solutions such as Graphile beats prisma 1 so much now.
Meanwhile they have been stuck for 2 years in their new weird direction of Prisma 2, with no results to show for, and no clear vision. The GraphQL server is gone, even though it was central to their product. Who cares about yet another ORM? I can generate types from any GraphQL endpoint automatically anyway!
Prisma became relevant during their Prisma 1 time, it was one of the first solutions to automatically generate GraphQL endpoints from DB schemas. It only had to keep going this way to lead the whole market. But they chose not too, and competing solutions such as Graphile beats prisma 1 so much now.
Meanwhile they have been stuck for 2 years in their new weird direction of Prisma 2, with no results to show for, and no clear vision. The GraphQL server is gone, even though it was central to their product. Who cares about yet another ORM? I can generate types from any GraphQL endpoint automatically anyway!
Not getting warm with any query/ORM library out there.
My own take of interfacing with an SQL database with Typescript: a query generator that uses mapped types a lot to infer result set types from queries and a schema file.
https://github.com/hoeck/typesafe-query-builder
Not sure if thats a good idea and if the Typescript inference even scales that well when using lots of tables.
Any feedback and criticism would be welcome.
My own take of interfacing with an SQL database with Typescript: a query generator that uses mapped types a lot to infer result set types from queries and a schema file.
https://github.com/hoeck/typesafe-query-builder
Not sure if thats a good idea and if the Typescript inference even scales that well when using lots of tables.
Any feedback and criticism would be welcome.