timsuchanek

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.

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.

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.

For anyone interested how a concrete implementation of this architecture can look like, we created an example project that includes the Gateway pattern with schema stitching and powerful resolver middlewares: https://github.com/graphcool/graphql-boilerplate