Personal response to this Twitter thread
I've just been taking a hard look at prisma. and to me it seems like crutch, rather than a solution. my guess is that it works for very simple stuff, but it's not usable for anything more or less "serious".
There are many serious developers and larger companies using Prisma in production today, such as adidas, HyreCar (recently IPOed) or Labelbox (just raised 10mio series A). We have no doubt that Prisma can be used for "serious" applications!
The docs are basically marketing material. "under the hood" doc provides no information I was hoping to find at least there. starting from "how queries are optimized"? some tutorial says there's a dataloader, but that's about it.
You're definitely right that our docs are lacking behind at the moment! We are working on the next iteration of the docs to be more reflective of Prisma's capabilities and how it actually works under the hood. Sorry for the current inconvenience on that end!
If you have concrete questions about certain topics (e.g. specific optimizations, how the dataloader is used, scaling Prisma, ...), feel free to open an issue in our content feedback repository or post your question in the forum.
Transactions sort of stop on nested inserts. which is great, but that's not how transactions are used. we don't create users with post and comments. rather, we like, deduct some money from some wallets while updating goods status and creating orders.
Transactions are indeed an interesting topic for us and it is true that our transaction API is fairly restricted at the moment. Our focus here so far was to meet the common needs of application developers instead of exposing low-level control. The tradeoff we therefore made was sacrificing control for ease-of-use. However, we are definitely considering expanding our transactions API. There are two types of transactions we're at least considering adding support for:
- Transactions where the submitted mutations do not have dependencies to each other, so they can all be submitted in a single HTTP request and don't require a long-lived connection between the client and the database. See this GitHub issue for more info. It's fairly certain that we'll add similar capabilities to Prisma soon.
- Transactions where the submitted mutations depend on each other. This is a lot more tricky for us since (as you already pointed out) Prisma is based on HTTP which follows a request-response-cycle. These kind of transactions require a long-lived connection between the client and the database. We're currently evaluating the use cases for this, but it's unclear if it will end up in the Prisma API. If you have a strong opinion about this, please share it in this GitHub issue.
Then there's an entire server piece. talking to the db over http (unless the client app is the thing that does the talking) is weird, isn't it? what does the server do that can't be generated straight in the client? exposes a graphql server playground?
The main reason why the Prisma server exists is because of Prisma's history and the fact that it was born out of Graphcool (which is a Backend-as-a-Service). While we see a lot of potential value in using this additional server component between your database and application server, we definitely acknowledge that it can be confusing for people starting out with Prisma that are "just looking for an ORM". That's why we are currently working on a version of that will make it possible to use the Prisma client without running an additional Prisma server (the very rough timeline for that is some time around May/June).
Nevertheless, we are going to continue to build out the Prisma server as we think that it can add a lot of value in the future, especially for more advanced/enterprise use cases. For example, we're planning to add caching and security capabilities to it. Having this extra layer that sees (and routes) all your database requests (especially if it's connected to multiple databases) is a great place to implement things like audit logging or other features that are critical in the enterprise world. Also note that the Prisma server is horizontally scalable, so it can be deployed as a multi-node cluster as well.
Benefits that the Prisma server buys you today already e.g. are the subscription API or that it enables connection pooling when used in the context of serverless functions.
Normally, an ORM allows everything that the underlying dmbs does allow, and does not do it at a cost of an extra architecture piece, and it's hard to see what value does Prisma bring to pay for that expense.
As mentioned in my original thread, the goal of Prisma is to find a more developer-friendly abstraction that makes it easy for developers to work with their databases. It is not necessarily the goal to mirror all capabilities of the DB, but the goal is to reduce unnecssary complexity and create a simpler mental model around your data while retaining the core benefits of each underlying DB. We're aware that our vision for Prisma is a technically very ambitious project, but we do have excellent engineers and are a well-funded company to take on such a challenge 🙂
And in case i'm wrong (which I don't mind at all to be), what's lacking from docs are some real under the hood things, such as benchmarks of Prisma vs connector/driver db access, at least with best case scenarios of both being in short proximity of each other. Are there any optimizations that happen on server? how do the underlying queries look like? all that sort of stuff would be useful.
I fully agree with you, I hope I could give you some more insights into why Prisma is what it is today and where we want to go with it in the future. It's definitely on us to communicate the value of Prisma better in the docs!
For me, the final blow was to find that the only aggregation function supported is count()
The aggregations API surely is a weak point and has been on our roadmap for a while, please take a look at the our plans for expanding the API here. If you have need to do any sort of aggregations, you currently need to drop down to raw SQL to achieve this with Prisma.
Thanks so much for sharing your feedback, this helps us a lot! I personally very much appreciate that your tone, while mildly provocative, was overall constructive and your points of cristicism absolutely valid. I'd love to see you around in our Slack or on GitHub 🙏