Prisma – Database tools for modern application development | Hacker News Reader

Prisma – Database tools for modern application development

prisma.io

243 pointsoctosphere83 comments

Back when prisma was emerging out of graphcool, every google documentation search sent me to graphcool, every graphcool page was full of broken links, and the shiny new prisma docs were unusable (including unviewable on my iPad that I use for researching tech I might use while sitting on the couch). It painted such a clear picture of a company that absolutely does not get the importance of API documentation to the success of an API that I've never been able to get myself to go back and give them a second evaluation.

Does their documentation today feel like the doc team and technical writing team have an actual seat at the table or does it still feel like the place is run by a bunch of architecture astronauts who think docs just happen after the fact?

Thanks for your upright feedback! You must have caught us in a bad moment, in the transition one year ago from Graphcool to Prisma we indeed needed to do a lot of work in the docs. Nowadays the Google experience should be much better, while our docs actually represent the product.

Would be great if you can give it another try, as I'm convinced that the docs improved significantly over the last year. Disclaimer: I work at Prisma.

They do look a lot better now in a way that suggests the doc side is maybe getting some actual love and attention. Will try to carve out some time to dig deeper.

I would say their docs are pretty good. It's pretty easy to pick up a Prisma app in just a single afternoon.

Docs are pretty horrible to read on my phone, chrome on Android. Panels are getting put side-by-side and the text inside is smashed to like 8 characters across. Too much whitespace. It's like ok ok you've gone and designed the fuck out of your page, but why'd ya have to do it to the docs? Unreadable. Since it sounds like the devs are watching this thread I figured I'd mention it.

(I work at Prisma)

It's true that we haven't focussed on a mobile experience for the docs so far (assuming a primary use case for the docs is when being used on your computer as you're using Prisma). However, we see that many people like to browse docs on their phones to learn about the tool, so we are now making it a priority to make our docs responsive! Thanks for the feedback.

It's been interesting watching Prisma, formerly Graphcool, transition from backend-as-a-service to open source backend to client ORM library. They also use bleeding edge patterns, so I always know where to go for examples as stuff gets adopted mainstream :) Keep up the good work Prisma team!

Question specific to this autogenerated client: does that mean I have to bump client version numbers every time my backend schema changes? Does this help if I'm building a backwards-compatible api, like Stripe's API [1]? Apologies if this is already answered in your docs.

[1]: https://stripe.com/blog/api-versioning

> They also use bleeding edge patterns, so I always know where to go for examples as stuff gets adopted mainstream :)

Do you have specific examples of cutting edge patterns they use that you can share? I'm always interested in seeing concrete examples of (often) abstract patterns/concepts.

(I work at Prisma)

Thanks a lot for the positive feedback, we appreciate it a lot! As to your question, I assume with "backend schema" you're talking about the Prisma datamodel? Whenever you change the datamodel, you're also re-generating your Prisma client. So, it can definitely make sense to version your Prisma client as your datamodel changes. Does this clear it up?

The main purpose of the code generation really is to have proper typings for all database operations based on the datamodel. For example, if you're adding a new model type to the datamodel, Prisma doesn't only generate according models in your programming language, it also generates types that facilitate filtering, pagination, ordering and any other operations of your database.

You've hit a GraphQL specific issue with APIs. Generally I think the best practice is to only make additive changes to your API and deprecate as necessary. GraphQL apis don't necessarily need versioning as the requests as it's much easier to continuously update them.

https://graphql.org/learn/best-practices/

Because the schema is updated on the Prisma server, I do think it could be possible to have multiple Prisma server running with different schema version.

The only issue that we did encounter so far is that it doesn't know play well easily when you have more than one instance of a Prisma server behind a load balancer that your backend connect to.

Prisma looks good and I hope it succeeds.

Another interesting and unique approach I'd love to see get more attention is Mammoth[0]. Instead of abstracting the database away, you define columns using its raw primitives (in this case, Postgres) and in return get a type-safe client, along with auto-generated migrations.

I imagine this approach allows you to leverage the features of the database much more easily. And Postgres has quite a lot of rich features to take advantage of! :)

[0]: https://github.com/Ff00ff/mammoth

Right, instead of abstracting away the database I think it makes sense to invest in making it attractive to use. Putting an abstraction layer (like ORM) on top of it basically hides it's amazing features.

PS. maintainer of mammoth here. Thanks for the mention.

I totally agree with this and this is actually very relevant for us at Prisma as we're supporting various kinds of databases. Our goal isn't to have one universal data access abstraction, but instead we want to ensure developers still get all the benefits of the databases they're using underneath (as all of them have different strengths and are great for different use cases)! We're currently working on an improved version of our data modelling language that will make it possible to model DB-specific properties (indices, special DB types, ...) into your Prisma datamodel, you can find the RFC for it here: https://github.com/prisma/rfcs

PS. We've looked into mammoth a lot for inspiration and really liked it, great work!

How is this different from any other ORM library?

You can think of Prisma as the next version of ORM technology. Prisma shares the same goals of an ORM (make data access easy), but takes a completely different approach than past ORMs.

Prisma uses introspection to generate a feature-rich, type-safe library around your database's schema to reduce or eliminate most of the downsides you traditionally associate with ORMs.

Type safety

Today's ORMs rely on query builders (e.g. await select('users').where('id', 10)) or hand-written classes (e.g. class Product < ApplicationRecord) to map an object to a row. Prisma looks to the database for the information about types and relationships to generate type-safe code specific to your database in every language (e.g. prisma.Products.FindByName("Sponge")).

Bugs caught at compile-time

Another downside of today's ORMs most of them break at runtime, rather than compile time. By generating type-safe database clients, Prisma eliminates any opportunity for breaking database changes to go unnoticed and end up in production.

Better performance

There are a couple advantages of Prisma has over traditional ORMs and raw SQL queries:

• The core of Prisma is written in Rust to have predictably high-performance and flexible caching.

• Prisma is written by database experts and administrators who have seen every database schema under the sun.

Fewer Leaks

Because Prisma has a holistic view of your database's structure, Prisma can generate an API that is better tailored to your application than a traditional ORM. There may be times when you still need to write raw database queries and Prisma will support these escape hatches, but those times are rare and are becoming less common every day.

I work at Prisma and this is one of the questions we're currently hearing the most (we'll actually publish a blog post about this exact question soon).

Generally, think of Prisma as a suite of database tools that simplify workflows in three different areas:

● Database access / ORM (lightweight, auto-generated and type-safe database client for various languages)

● Declarative data modelling and migrations

● Data management with modern admin UI

I think it also differs from traditional ORMs in that it supports multiple databases. We see a trend that many modern apps are built on top of a variety of databases, it might use Posgtres, Elastic, Mongo and Neo4j all at the same time for different purposes. We are embracing this and with the Prisma client it will be possible in the future to access all these data sources in a single, coherent and type-safe API.

Feel free to check out our roadmap to get an idea of what we're working on: https://github.com/prisma/prisma/blob/master/ROADMAP.md

I will never understand the desire to add ever more layers to well understood patterns and services. I fail to see the value add of prisma over any decent database.

It’s not a database.

SQL isn’t typed. And writing migrations and client libraries is otherwise painful. That’s basically the value add.

Sql is not only typed, its very strongly typed. Please dont confuse the lack of explicit annotations in typical sql for a lack of types. Sql is the prototypical killer app for type inference. Its so good, most people think it's untyped

Right. I think it was fairly clear what I meant, since Prisma cannot really help to change postgres internals (and strict typing in mysql is a bit hit&miss in the first place), but for the sake of everyone else reading this:

SQL results, coming without any translation layer, are untyped. Your result could be anything from a string to an array with an infinite number of fields.

It doesn’t really get more structure than this big array either, regardless of table representation.

Prisma helps with that.

> SQL results, coming without any translation layer, are untyped.

That would depend on the database's wire protocol, wouldn't it?

Do I really have to qualify this with ‘mainstream databases, with mainstream client libraries, in nearly all major languages’?

Mainstream databases like Postgres and SQL server (and MySQL too I think) all return type information with their results. Having written wire protocol clients for these, I flat out reject your claim that SQL isn't typed at the results level. It's one of the few places in common usage that the types are explicitly stated. Whether or not your client libraries reflect that is a different issue (and if they don't, I encourage you to use something better).

I don't know. That's why I asked. I did a quick lookup of libpq and it gave the impression that it can answer for column types.

I’ve tried Prisma over the last few months, but eventually decided against adopting it in our product because it seems very inflexible when working with many-to-many relationships. In particular, filtering on foreign keys doesn’t seem possible and requires SQL table joins, which (in our case) has an immensely negative performance impact. Also, the query chaining API doesn’t lend itself well to filtering on multiple relationships. Apart from that, the idea seems really cool and I’m sure the project has a great future ahead of it!

Thanks for that honest feedback! That was indeed a drawback we had and we often had this point coming up in customer conversations. This is why we started an effort to lift this limitation a few months ago. The result of this work is a new Datamodel specification that allows you to take full control of how relations are implemented. You can check it out here: [GitHub - prisma/datamodel-v1.1-feedback](https://github.com/prisma/datamodel-v1.1-feedback) Your use case description sounds like you want to take really control of a lot of details here. Therefore I would suggest you to introduce a model that is backed by your relation table. Then you can freely filter on this model and then traverse relationships from there. If you want to chat more about how to implement in detail feel free to reach out on our public Slack (my nick there is: marcus).

People facing similar issues might want to try out GRelDAL [1] (disclaimer: I am the author), a simple node.js library for bridging relational databases to graphql APIs.

It supports various strategies for loading associations, including joins and bulk sideloading (pre-edge when you know what to fetch before parent entities have been loaded, and post-edge when you need parent entities before).

It is still somewhat early stage and the scope is much narrower but it provides a great deal of control to the host application on how the operations are mapped from the graphql layer to the persistence layer.

[1] https://gql-dal.github.io/greldal/

Forgive me if I’m missing something here, but joins seem pretty much the only way to do performant foreign key filtering to me.

Is this not what you were talking about?

It wasn't my question, but I would assume the caveat they were complaining about is that prisma forced them to perform the join when filtering the original table by just the foreign key (think select * from books where author_id = ? ... no join to aauthors needed here, but some ORMs do that join anyways)

I've been using Prisma for most of the last year in personal projects and I have to say it has been the absolute easiest database layer I've ever used. My development experience has been immensely streamlined.

I work at Prisma and it's really awesome to hear such feedback! Please let us know if you have any further questions, we're happy to help :)

Unless you have specific requirements, Ive always found prisms to be bloated / heavy. I prefer Hasura.

There is also PostGraphile to turn your DB into a GraphQL API: https://www.graphile.org/postgraphile/

Do you have examples of specific requirements for which Prisma would be a good fit?

Prisma is good for writing data models, running migrations. The new admin is very usable already, although still beta. I've been very productive loading, editing and querying data.

Hasura I think is good for preexisting db, no migrations? I haven't evaluated it fully.

(I work at Hasura)

Yep! We’ve put in a lot of effort to ensure hasura Just Works on an existing db.

Incidentally, to address your last point, Hasura has its own rails like migrations system and an admin UI (that allows DDL and DML) and works well with your existing migrations tooling too if you have it already. The hasura admin UI can create the rails style migration files automatically on your disk as you work on the UI.

https://hasura.io/all-features

First time learning about Hasura. Looks really promising with the built-in _live queries_ support, which Prisma has not yet implemented (they only have subscriptions): https://github.com/prisma/prisma/issues/1205

EDIT: Never mind, looking at the docs, it looks like they also only support subscriptions... It's understandable to not have support for live queries yet, as it's still a very under-explored territory, but it's still misleading marketing on their part because they explicitly call out support for subscripts _and_ live queries on their website.

Curious how Hasura tackles the N+1 problem for efficient querying in GraphQL? Prisma uses a built-in dataloader implementation for this but I couldn't find anything about query optimization in the Hasura docs.

Also, in the docs on pagination: https://docs.hasura.io/1.0/graphql/manual/queries/pagination...

I'm only seeing examples of offset-based pagination. Is cursor-based pagination on the roadmap as well?

Answering a few points:

Hasura allows you to turn any "query" to a subscription, essentially live queries.

Hasura's query optimization is actually one of the core features. Hasura is structured as a transpiler that converts GraphQL, adds access control clauses and then renders a single SQL for the database. Very different from a typical ORM approach or the dataloader approach.

More details: https://blog.hasura.io/architecture-of-a-high-performance-gr...

We have been using Prisma for our newest project, and have really enjoyed it! The development experience is unparalleled in the Node.js world, it lets us move so quickly.

There are some rough edges, but the team is very responsive and they have fixed most of my minor gripes over the past months.

Overall I am happy we chose it and I would choose it again.

Thanks a lot for the feedback Max, we really appreciate it! We're currently working on many improvements (e.g. a more powerful data modelling syntax, a sophisticated migration system, opening up the database connector and client generator APIs, ...) for Prisma that you can check out in our RFCs: https://github.com/prisma/rfcs

Hm... is this is like JOOQ[1] for non-Java languages? Or maybe more like a typed version of massivejs[2]?

[1] https://www.jooq.org/ [2] https://massivejs.org/

No Prisma is not like JOOQ. We are happily using JOOQ internally at Prisma so i happen to know. The main differences in my opinion are: - JOOQ is a SQL Query Builder which is typesafe in regards to the fact that you cannot make SQL syntax errors in your query. However you can still write queries that are e.g. using a table that does not exist. In contrast the Prisma Client gets generated for all your tables and columns and this error is impossible. You also don't need to do any mapping from SQL result sets to your application models. - JOOQ is about SQL. Prisma is not only about SQL but also any other kind of database. Prismas architecture is comprised of a database agnostic core and database specific connectors. Therefore it can connect to any database for which a connector exists. Right now we have connectors for Postgres, MySQL and MongoDB. More are in the works and in the future people will be able to implement their own connectors :-) - Prisma has a migration system but JOOQ does not have one.

jooq can also introspect your database and ensure you only use existing tables and columns and your data types are in agreement

it however requires you do this at compile time, not runtime. does prisma do the introspection at runtime?

Sorry for being out of context, but why is your name in green? This is the first time I have seen a green name in HN.

new accounts (below 14 days I think) are colored green.

I've been using Prisma in for some months now (even in production), and I'm a big fan of the product. With TypeScript you have an easy full autocompletion & type checking over your models, and coupled with a graphql-yoga server & graphqlgen for the exposed GraphQL part it has been a pretty nice experience.

The downside is (because there is always some), as it's a new tech, problems can pop up and more research have to be made compared to a more old and popular framework.

In any case, I highly recommend you to try it on your own, I'm looking foward to its futur improvements.

Thanks so much for your positive feedback, we really appreciate it! We indeed have many exciting improvements in the store, to get an overview of those feel free to check out our RFCs: https://github.com/prisma/rfcs Also, if you're building a GraphQL server you might want to check out GraphQL Nexus which is an alternative to the SDL-first approach taken with `graphqlgen`: https://www.prisma.io/blog/using-graphql-nexus-with-a-databa...

To be fair. That Golang implementation looks overly verbose. I mean compare the Typescript and Golang implementation. The Golang one isn't even readable. I'd personally use something else instead.

That is a fair point. The current Golang implementation is the first one we did. Right now we are working on a new version of the Prisma Client. And the Golang version will get a lot of love over the coming weeks.

Totally agree! I'm actually working on improving the Go API right now. We'll have a new API in the coming weeks that should look a lot more idiomatic :-)

Pardon the ignorance because the site isn’t super clear - but is this just an ORM library for the JavaScript/Typescript ecosystem? How does it “replace” a traditional ORM exactly?

It's a GraphQL ORM and it runs in it's own process on top of whatever db you have, whether Mongo or Postgres. You can use it with any programming language but I think their support is best for Node and Go.

Ah so this is similar to Hasura.

I work at Prisma, we've recently written a blog post about exactly this question where we also compare Prisma to other services like Hasura or AWS AppSync: https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c/

Relevant parts:

> Comparing Prisma to AWS AppSync & Hasura

> With the new understanding of the role of Prisma's CRUD GraphQL API, it becomes clear that Prisma is not in the category of "GraphQL-as-a-Service" anymore.

> Tools like AWS AppSync and Hasura provision a generated GraphQL API for your database (or in the case of AppSync also other data sources). In contrast, Prisma enables simplified and type-safe database access in various languages.

Looks like the traditional caveats for ORMs would apply here. Many painful lessons have been learned in that field.

What would be interesting to see is the cost of change i.e. how de-coupled things are to make changes simple.

Changes like: Adding a field To changing a relationship between entities and such.

That's a good question. As long as you have additive changes, Prisma can do the change automatically for you. As soon as it's a change where anything will be dropped (field, relationship etc), Prisma will prompt you and ask if you want to perform that breaking change. The only command you need to know for data model changes is `prisma deploy`. Disclaimer: I work at Prisma.

As someone who has been using Prisma religiously for the past year, I would like to express that this is the largest pain point of working with the platform. Not having the ability to custom define these transformations is brutal.

That is great to hear! Because we're working on exactly fixing that! What is the concrete limitation you're hitting with that?

When I first saw prisma I was blown away but after a couple months of trying to get a production ready system online I was just fed up with the "schema first" pattern. Wasted way too much time adapting the schema for custom types. I was about take it behind the shed and feed it a bullet until nexus/nexus-prisma came along. It was perfect timing in my case, I now love prisma again.

Thanks a lot for this feedback and great to hear you like the code-first approach of GraphQL Nexus for building your GraphQL server!

For anyone who is curious about Nexus, I recommend our blog article series about code-first vs SDL/schema-first GraphQL server development: https://www.prisma.io/blog/the-problems-of-schema-first-grap...

Also, for a quick and ready-to-run example, you can check out this: https://github.com/prisma/prisma-examples/tree/master/node/g...

What is Prisma actually? Is it an ORM or a client for a db that exposes a GraphQL API for the data stored?

That's a good question.

The main focus of Prisma is the ORM part and not the GraphQL API anymore. We're still using GraphQL to communicate between Query Engine and the backend client in the languages we support like TypeScript or Go, but when communicating with backend to database, GraphQL is not that relevant anymore and rather a separate concern how you want to expose your API later.

When accessing the database from your backend, type-safety is becoming more and more important. Instead of writing a GraphQL string in your code, with the Prisma Client you get a type-safe programmatic API to access your data. You can imagine it as your own SDK. The difference to many ORMs is, that we generate a custom Client for you, which is way more powerful.

Disclaimer: I work at Prisma.

This is a very common question, we actually recently wrote a blog post about exactly this topic: https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c/

Hopefully that clears it up!

So If I understand it right, this is an ORM (with some graphql like properties) with the addition of data model code generation?

it's more than just a traditional ORM layer. They run a server (prisma) between the client and the database.

This is really not clear from the site. Even after I skimmed the tutorials and docs. I would imagine it should be front and center like in Hasura and Postgraphile . I would be tiffed if I found out after I started developing with it using the cli that I need to setup another server and process in my production environment.

(I work at Prisma)

It is very important to understand that Prisma is NOT a GraphQL-as-a-Service like Hasura or Postgraphile. It's really a suite of database tools that you can use for any use case (building GraphQL, REST or gRPC APIs, or use it in any other app where you need a database). We recently wrote a blog post about this topic: https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c/

Also, the Prisma server (that proxies the database) is indeed currently a mandatory component in the Prisma architecture. However, this requirement will be lifted very soon (as we're currently rewriting the Prisma core in Rust) and it will be possible to run Prisma as a library, just like any other ORM.

It feels a bit misleading to say PostGraphile is "GraphQL-as-a-Service". Typically XaaS is used when there's an external service (normally hosted elsewhere) that provides this functionality; whereas PostGraphile is 100% self-hosted, we do not even have a hosted offering. Further, PostGraphile is more of a framework for building a GraphQL API than a separate service you run - since it's pure JS (well, TypeScript) a decent portion of our users mount PostGraphile directly into their Express or Koa applications and deeply integrate it, including customising and extending it via plugins. It's much more of a library/framework than an "-as-a-service". (I'm the PostGraphile maintainer.)

Massively simplifies working with data and databases cos they don't use ORM.

This is amazing! What about Python?

Between SQLalchemy, Django, Peewee, and quite a few others, Python is fairly well-covered by ORMs already.

Don't the Django ORM and Django Admin do the same thing?

Prisma admin is much better for editing relationships. Write graphql queries with deep multilevel joins and then double click to edit any fields you see in the results. Very different experience than django.

I would suspect the Django Admin is built on top of Django ORM.

Is this a library? A server? Something else? It looks like a business, so what's for sale?

(I work at Prisma)

Prisma is open-source and you are typically running it in production by running it on your own cloud infrastructure.

The commercial parts of Prisma are called Prisma Cloud and Prisma Enterprise. Prisma Cloud aims to simplify various Prisma workflows such as server and data management, monitoring, backups, migrations/rollbacks, ... We're also planning a "Prisma Serverless" offering so you don't need to host the Prisma server yourself.

Forgive me the obvious elephant in the room - where is Swift and Java/Kotlin support?

(I work at Prisma)

That's a great question! We started with a major focus on GraphQL which has now become more generic as Prisma can really be used for any app that uses a DB (REST, gRPC, ...). With that GraphQL history, we've put a lot of focus on the Node/TypeScript ecosystem because that's where GraphQL tooling is most mature. However, we're definitely planning to support more languages in the future. In particular, we are opening the generator API for the Prisma client which means it will be possible for anyone to implement the Prisma client in their own preferred language: https://github.com/prisma/rfcs/blob/client-generators/text/0...

Written in Scala, has a "greyed out" Python and Java client icon in the diagram at the very top of the readme, and an issue from Jan 2018 querying about a Java client which has had barely any traffic.

That's slightly weird, bit of a mixed messages situation!

Epilogue: Caveat emptor, rambling ahead. I probably shouldn't write comments when I'm tired.

Hasn't type safe ORM mappings and/or middleware, code generation, been done to death, at least for the JVM languages?

However, as I've been out of the Java loop for a bit, I'm not 100% sure of the stage of ORM like tools/libs today, I might be wrong.

If the admin UI is spectacular, and the migration flawless even with a fair bit of data, those could be useful tools. Neither are easy tasks though.

But still, I have to wonder, is there actually more ways to try to do it, to connect code and relational/graph data?

Feels like there has been so many attempts and that all of them has shown to have their various, by now, surely rather well known limitations?

Better is always possible, though.

However, except for mixing in a bit of graphql and having an additional server, I can't really see what it is they claim is so different?

Though I've been out of the loop for some year I can't have been the only one that have implemented/integrated a graph querying language on top of a ORM(-like) mapping with code generation, similar to Prisma? Or are there really no decent tooling of that kind, still?

Except for admin UI and real-time, I wrote something very similar back in 2007, or something like that. Unfortunately my client weren't interested in open sourcing it, back then it could have been somewhat original.

If I recall correctly, it was a customized Hibernate in the bottom, some code generation for Java - ASP - php - and maybe perl - clients, some fancy dependency injection.

Connect to the database and you got generated all code that was needed for a service you could query for tree fragments of almost arbitrary shape.

Essentially a GraphQL light I quess, as GraphQL wasn't available at the time, if it existed at all.

The http API used JAXWS I believe and it exposed few endpoints for some REST-ish+JSON and SOAP

You could do transactions over multiple requests if you wanted to, and weren't easily scared.

It could obviously prune circular graphs into trees, although that code had a few fun bugs initially.

No streaming though, as the client didn't need it.

For Kotlin/Java you can probably use jOOQ (https://www.jooq.org/)

Prisma is meant to be a backend ORM so a swift implementation makes little sense.

Reply on news.ycombinator.com