20 ms·

Prisma – Database tools for modern application development

243 points by octosphere 8y ago

tdhz77 8y ago
Unless you have specific requirements, Ive always found prisms to be bloated / heavy. I prefer Hasura.
- aclemmensen 8y ago
  Do you have examples of specific requirements for which Prisma would be a good fit?
  - crucialfelix 8y ago
    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.
    - tango12 8y ago
      (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 https://hasura.io/all-features
      - lewisl9029 8y ago
        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 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.html 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?
        tango12 8y ago
        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-graphql-to-sql-server-58d9944b8a87 https://blog.hasura.io/architecture-of-a-high-performance-gr...
- taffer 8y ago
  There is also PostGraphile to turn your DB into a GraphQL API: https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/
welder 8y ago
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 https://stripe.com/blog/api-versioning
- c036 8y ago
  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.
- jhalstead 8y ago
  > 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.
  - deleted 8y ago
    [deleted]
- hokumguru 8y ago
  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/ https://graphql.org/learn/best-practices/
- nikolasburk 8y ago
c036 8y ago
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.
- nikolasburk 8y ago
  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 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-database-pmyl3660ncst https://www.prisma.io/blog/using-graphql-nexus-with-a-databa...
glutamate 8y ago
How is this different from any other ORM library?
- matthewmueller 8y ago
  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.
- nikolasburk 8y ago
  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 https://github.com/prisma/prisma/blob/master/ROADMAP.md
iddan 8y ago
This is amazing! What about Python?
- stefano 8y ago
  Don't the Django ORM and Django Admin do the same thing?
  - vbsteven 8y ago
    I would suspect the Django Admin is built on top of Django ORM.
  - crucialfelix 8y ago
    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.
- bshipp 8y ago
  Between SQLalchemy, Django, Peewee, and quite a few others, Python is fairly well-covered by ORMs already.
hokumguru 8y ago
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.
- nikolasburk 8y ago
  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 :)
deleted 8y ago
[deleted]
programmerzdojo 8y ago
is this different from any other ORM library?
alexashka 8y ago
Forgive me the obvious elephant in the room - where is Swift and Java/Kotlin support?
- RandomBK 8y ago
  For Kotlin/Java you can probably use jOOQ (https://www.jooq.org/ https://www.jooq.org/)
- lostmyoldone 8y ago
  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.
monteverdi 8y ago
Massively simplifies working with data and databases cos they don't use ORM.
yodon 8y ago
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?
- chrisco255 8y ago
  I would say their docs are pretty good. It's pretty easy to pick up a Prisma app in just a single afternoon.
- timsuchanek 8y ago
  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.
  - yodon 8y ago
    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.
- coleifer 8y ago
  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.
viksit 8y ago
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?
- chrisco255 8y ago
  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.
  - viksit 8y ago
    Ah so this is similar to Hasura.
    - nikolasburk 8y ago
      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/ https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c/
      - joshstrange 8y ago
        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.
tathougies 8y ago
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.
- Aeolun 8y ago
  It’s not a database. SQL isn’t typed. And writing migrations and client libraries is otherwise painful. That’s basically the value add.
  - tathougies 8y ago
    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
    - Aeolun 8y ago
      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.
      - jacques_chester 8y ago
        > SQL results, coming without any translation layer, are untyped. That would depend on the database's wire protocol, wouldn't it?
        Aeolun 8y ago
        Do I really have to qualify this with ‘mainstream databases, with mainstream client libraries, in nearly all major languages’?
turboturbo 8y ago
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!
- Aeolun 8y ago
  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?
  - kilburn 8y ago
    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)
- lf-non 8y ago
  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/ https://gql-dal.github.io/greldal/
- mavilein 8y ago
  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 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).
simplify 8y ago
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 https://github.com/Ff00ff/mammoth
- martijndeh 8y ago
  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.
  - nikolasburk 8y ago
    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 https://github.com/prisma/rfcs PS. We've looked into mammoth a lot for inspiration and really liked it, great work!
Improvotter 8y ago
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.
- mavilein 8y ago
  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.
- matthewmueller 8y ago
  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 :-)
tiuPapa 8y ago
What is Prisma actually? Is it an ORM or a client for a db that exposes a GraphQL API for the data stored?
- timsuchanek 8y ago
  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.
- nikolasburk 8y ago
  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/ https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c/ Hopefully that clears it up!
beders 8y ago
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.
- timsuchanek 8y ago
  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.
  - hokumguru 8y ago
    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.
    - derdude 8y ago
      That is great to hear! Because we're working on exactly fixing that! What is the concrete limitation you're hitting with that?
coleifer 8y ago
Is this a library? A server? Something else? It looks like a business, so what's for sale?
- nikolasburk 8y ago
  (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.
hn_reddit_human 8y ago
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/ https://www.jooq.org/ [2] https://massivejs.org/ https://massivejs.org/
- rishav_sharan 8y ago
  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.
  - Illniyar 8y ago
    new accounts (below 14 days I think) are colored green.
  - deleted 8y ago
    [deleted]
- mavilein 8y ago
  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.
  - querulous 8y ago
    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?
mxstbr 8y ago
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.
- nikolasburk 8y ago
  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 https://github.com/prisma/rfcs
Illniyar 8y ago
So If I understand it right, this is an ORM (with some graphql like properties) with the addition of data model code generation?
- shusson 8y ago
  it's more than just a traditional ORM layer. They run a server (prisma) between the client and the database.
  - Illniyar 8y ago
    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.
    - nikolasburk 8y ago
      (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/ 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.
      - BenjieGillam 8y ago
        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.)
shean_massey 8y ago
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.
- nikolasburk 8y ago
  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-graphql-development-x1mn4cb0tyl3/ 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/graphql https://github.com/prisma/prisma-examples/tree/master/node/g...

243 points by octosphere 8y ago

tdhz77 8y ago

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

aclemmensen 8y ago
Do you have examples of specific requirements for which Prisma would be a good fit?
- crucialfelix 8y ago
  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.
  - tango12 8y ago
    (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 https://hasura.io/all-features
    - lewisl9029 8y ago
      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 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.html 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?
      - tango12 8y ago
        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-graphql-to-sql-server-58d9944b8a87 https://blog.hasura.io/architecture-of-a-high-performance-gr...
taffer 8y ago
There is also PostGraphile to turn your DB into a GraphQL API: https://www.graphile.org/postgraphile/ https://www.graphile.org/postgraphile/

welder 8y ago

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 https://stripe.com/blog/api-versioning

c036 8y ago
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.
jhalstead 8y ago
> 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.
- deleted 8y ago
  [deleted]
hokumguru 8y ago
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/ https://graphql.org/learn/best-practices/
nikolasburk 8y ago

c036 8y ago

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.

nikolasburk 8y ago
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 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-database-pmyl3660ncst https://www.prisma.io/blog/using-graphql-nexus-with-a-databa...

glutamate 8y ago

How is this different from any other ORM library?

matthewmueller 8y ago
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.
nikolasburk 8y ago
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 https://github.com/prisma/prisma/blob/master/ROADMAP.md

iddan 8y ago

This is amazing! What about Python?

stefano 8y ago
Don't the Django ORM and Django Admin do the same thing?
- vbsteven 8y ago
  I would suspect the Django Admin is built on top of Django ORM.
- crucialfelix 8y ago
  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.
bshipp 8y ago
Between SQLalchemy, Django, Peewee, and quite a few others, Python is fairly well-covered by ORMs already.

hokumguru 8y ago

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.

nikolasburk 8y ago
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 :)

deleted 8y ago

[deleted]

programmerzdojo 8y ago

is this different from any other ORM library?

alexashka 8y ago

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

RandomBK 8y ago
For Kotlin/Java you can probably use jOOQ (https://www.jooq.org/ https://www.jooq.org/)
lostmyoldone 8y ago
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.

monteverdi 8y ago

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

yodon 8y ago

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?

chrisco255 8y ago
I would say their docs are pretty good. It's pretty easy to pick up a Prisma app in just a single afternoon.
timsuchanek 8y ago
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.
- yodon 8y ago
  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.
coleifer 8y ago
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.

viksit 8y ago

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?

chrisco255 8y ago
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.
- viksit 8y ago
  Ah so this is similar to Hasura.
  - nikolasburk 8y ago
    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/ https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c/
    - joshstrange 8y ago
      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.

tathougies 8y ago

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.

Aeolun 8y ago
It’s not a database. SQL isn’t typed. And writing migrations and client libraries is otherwise painful. That’s basically the value add.
- tathougies 8y ago
  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
  - Aeolun 8y ago
    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.
    - jacques_chester 8y ago
      > SQL results, coming without any translation layer, are untyped. That would depend on the database's wire protocol, wouldn't it?
      - Aeolun 8y ago
        Do I really have to qualify this with ‘mainstream databases, with mainstream client libraries, in nearly all major languages’?

turboturbo 8y ago

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!

Aeolun 8y ago
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?
- kilburn 8y ago
  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)
lf-non 8y ago
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/ https://gql-dal.github.io/greldal/
mavilein 8y ago
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 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).

simplify 8y ago

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 https://github.com/Ff00ff/mammoth

martijndeh 8y ago
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.
- nikolasburk 8y ago
  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 https://github.com/prisma/rfcs PS. We've looked into mammoth a lot for inspiration and really liked it, great work!

Improvotter 8y ago

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.

mavilein 8y ago
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.
matthewmueller 8y ago
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 :-)

tiuPapa 8y ago

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

timsuchanek 8y ago
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.
nikolasburk 8y ago
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/ https://www.prisma.io/blog/prisma-and-graphql-mfl5y2r7t49c/ Hopefully that clears it up!

beders 8y ago

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.

timsuchanek 8y ago
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.
- hokumguru 8y ago
  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.
  - derdude 8y ago
    That is great to hear! Because we're working on exactly fixing that! What is the concrete limitation you're hitting with that?

coleifer 8y ago

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

nikolasburk 8y ago
(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.

hn_reddit_human 8y ago

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/ https://www.jooq.org/ [2] https://massivejs.org/ https://massivejs.org/

rishav_sharan 8y ago
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.
- Illniyar 8y ago
  new accounts (below 14 days I think) are colored green.
- deleted 8y ago
  [deleted]
mavilein 8y ago
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.
- querulous 8y ago
  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?

mxstbr 8y ago

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.

nikolasburk 8y ago
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 https://github.com/prisma/rfcs

Illniyar 8y ago

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

shusson 8y ago
it's more than just a traditional ORM layer. They run a server (prisma) between the client and the database.
- Illniyar 8y ago
  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.
  - nikolasburk 8y ago
    (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/ 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.
    - BenjieGillam 8y ago
      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.)

shean_massey 8y ago

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.

nikolasburk 8y ago
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-graphql-development-x1mn4cb0tyl3/ 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/graphql https://github.com/prisma/prisma-examples/tree/master/node/g...