1,624 karma · joined October 17, 2010
If you are a grumpy HN troll, then Prisma might not be for you, and that's okay. SQL is great for many cases, and you might not need to expand your horizon.
If you do choose to look into Prisma and have serious thoughts on how we could improve, then I would love to get on a call to talk about it (contact info in bio).
If you liked the developer experience in the .NET ecosystem but find yourself needing to work with JavaScript or Go, you'll probably like Prisma.
There are an order of magnitude more application developers today than just 10 years ago. This enable us to invest much more in the tools we all use, resulting in higher quality and a much better experience.
So to turn it around - why _not_ build new and better tools?
Have you tried https://redwoodjs.com/ or https://blitzjs.com/ ?
They both build on Prisma core data abstractions and provide a more full-featured experience. There will be talks later today at prisma.io/day
If you give it a try and have a database handy, I bet you can have it up and running in less than 10 minutes.
I'm the co-founder of Prisma, so should be able to answer some of your questions :-)
Prisma has a Query Engine written in Rust, and a language binding for each target language. Currently we only support JavaScript and TypeScript, but a binding for Go is already in the works. As Sytten alluded to, this split allow us to write and test all the logic once, and have a relatively thin layer that is only concerned about presenting an ergonomic API following the idioms specific to a given language. Now, as you mention, this introduces a bit of extra work on our part, and the potential for bugs when the two sides don't add up. But this problem is very minimal in practice, and in fact most features can be implemented with just a change on the Rust side, as the language bindings are generated based on a API description emitted by the Rust binary.
Another reason for the split is performance. It's reasonable to ask how performant a library that simply marshals some data from a database really has to be. But it is important to realise that Prisma Client is quite a bit more ambitious than that. Where other libraries usually tries to generate a single complex query, Prisma will often issue multiple smaller queries and partly join the data in memory. The throughput difference between V8 and Rust is significant here.
You are right that our architecture precludes us from doing things like explicitly starting a transaction and keeping it open for a longer duration of time. Our long-term goal is to create an Application Data Platform for medium-sized software development teams that can't afford to invest in internal infrastructure to the same degree as big tech companies. If you are curious what this might look like, you can take a look at TAO at Facebook or Strato at Twitter. For long running transactions specifically, we believe that they are often misused by developers who think they get a certain guarantee that they don't actually get from wrapping their workload in a transaction. There are often better approaches - both more correct, and easier to reason about, and that's what we want to teach people.
Currently we are building 30+ different binaries for each release in order to support most sensible platforms. This is a pain for us, but I hope most of our users will see that this is something they rarely have to worry about if at all. We believe that WASM + WASI will enable us to eventually remove the need for the binary for Applications running on Node, but the ecosystem is not quite there yet.
Ultimately, I think the biggest step forward represented by Prisma 2 is the type safety and result typing. We have been pushing the TS compiler to its limits, and I believe the developer experience speaks for itself. We have a lot of work to do in order to build out the feature set, but I hope many developers will appreciate the improved ergonomics, and trust that we will work diligently over the coming months to add the features that they need.
Thank you for looking into Prisma!
- 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.
Huge shoutout to everyone working on Rust Async, especially the Berlin crew, who has been very helpful.
By rewriting small components and integrating them into the existing project using Javas native interface, our small team of 5 developers were able to pull off this massive rewrite in just under a year. The resulting code base is rearchitected in a few very important ways, but mostly follows the same structure.
And because we kept and evolved our old Scala based test suite, we have a very high confidence in the rewrite.
When Async/.await finally landed, we could switch over very quickly, and it has been a joy to focus on benchmarks and performance over the last month. Spoiler: Rust is faster than Scala :-D
At Prisma we are building the data layer for modern applications. If you are fascinated by the software that power large technology companies such as Twitter, Airbnb and Facebook but want the challenges and freedom that come with working in a small startup, then a job at Prisma might be for you.
Our tech is open source, so go take a look at https://github.com/prisma/prisma
Apply here: https://boards.greenhouse.io/prisma/jobs/4110596002 All open positions: https://www.prisma.io/jobs
You should think of Prisma as the data layer for your applications. If you look at large tech companies who are typically ahead of the status quo for how to build applications, then you see that there is a trend to move away from traditional ORMs.
Twitter has a service called Strato that manages data access for all their services. Facebook has TAO that serves a similar role. Prisma is an open source implementation of that pattern.
If you are building a GraphQL API using for example Graphene, then you could use Prisma as your data layer, but Prisma can also be used in non-GraphQL applications. If you are using the Nodejs implementation, then you can take advantage of schema delegation to simplify the implementation of your resolvers. The GraphQL ecosystem is still evolving, so these capabilities will come to more languages in the future.
So in short - Prisma replaces SQLAlchemy, not Graphene. Hope that provides some clarity :-)
As you work at Hasura I assume you are aware that Prisma does work with existing postgres databases. You can look up the documentation for introspecting an existing database at https://www.prisma.io/docs/reference/service-configuration/d...
Full disclosure - I am the co-founder of Prisma.
If you look at the architecture of modern tech companies they are already moving in this direction. Facebook has TAO for data access, and twitter has Strato: https://about.sourcegraph.com/graphql/graphql-at-twitter/ The purpose of these data services is to enable feature developers to focus on their feature instead of worrying about infrastructure, caching and scalability. Prisma is an open source version of that same pattern.
To the question of whether you should expose your database API to other internal services or not. This very much depends on the kind of architecture you are choosing. If you are building microservices you typically want to ensure that only the microservice owning the data can access and update it.
Facebook has a quite different approach where TAO enforces access control policies, and all services can query the same data. We'll explore how Prisma can support this pattern in the future.
Adamkl is right, you are missing a layer in your application. postgraphile, prisma and hasura turn your database into a graphql api, but you don't want to expose that directly. Graphql Bindings allow you to construct a Graphql Api by mapping an existing Api and implementing extra logic.
This allows you to keep permission and business logic in your application layer where it belongs.
My Co-founder Johannes is giving a talk on this technique at GraphQL Europe on Friday. The talks will be available online shortly after, so I would recommend keeping an eye out for that if you are not going.
The Graphcool Framework uses an approach similar to what Hasura is doing, but there are many use cases where this is simply not flexible enough.
AppSync has rudimentary support, which is basically a fork of the Apollo Client as far as I understand it.
There is also some movement in the open source ecosystem, for example https://github.com/Malpaux/apollo-offline
As you can read about here https://blog.graph.cool/all-you-need-to-know-about-apollo-cl... the Apollo client was recently rewritten to be more modular, enabling faster innovation on features such as offline support.
We have raised $4.5M from KP, but Prisma stays open source. Happy to answer any questions about Prisma, GraphQL and databases :-)