Type-graphql: Integration with Prisma

[MichalLytek]

_Originally posted by @ntziolis in https://github.com/19majkel94/type-graphql/issues/77#issuecomment-449631177_

There are various reasons why we feel when solving this issue a lot of other goodness would come from it:

• prisma has a VERY poor data model migration story, in particular:
  
  
  
  • no versioning of schema during dev time
  
  
  • deployment of the same schema causes deployment errors in many cases breaking CI pipelines
  
  
  • no support for up/down migrations
  
  
• using partial or changed types in public schema only possible via copy&paste
  
  
  
  • using the same types in your public schema minus a few fields requires copy&pasting the type (and related types) and manually removing the fields in question
  
  
  • causes errors when our devs update prisma data model but forget todo the same on the public side (lets be honest this happens a lot)
  
  

In order to clean this up and follow DRY here is how we wanted to use type-graphql

• type-graphql becomes our way of defining both public & prisma schema
• at the same time be able to generate type safe resolvers for the public schema
• and use the additional features to standardize on DI etc most of which is handled manually / project by project today with different libs

I understand this might have been the initial intention of type-graphql but I can tell you after the 10th+ graphql project: The need for a framework that is the beginning and end where types originate is VERY high especially when using a graphql datasource underneath (we have tried various beyond prisma).

[ntziolis]

I should add, being able to control the schema via code would also allow for up/down migrations to be coded. While its possible todo this today it would mean creating yet another instance of the schema in another language to be able to manipulate it.

[bmayen]

This is a killer feature that would really drive adoption of type-graphq via the Prisma community. Prisma's generator uses the SDL as the source of truth and requires manual copy/paste to keep everything in sync. If type-graphql could be used instead, I imagine it would be the goto solution for Prisma users.

[MichalLytek]

@bmayen
The Prisma Team choosed other approach for creating schema and types:
https://github.com/prisma/nexus-prisma

I will look where this approach will lead us and if there is a gap, I will for sure try to fill it with decorators 😉

[bmayen]

Might make sense for Nexus to support decorators natively. Opened an issue there to see what their thoughts are.

[schickling]

Hi @19majkel94! We're still very interested in supporting you with a seamless Prisma integration. Given the very nature of developers, there will always be some opinionated preferences and we're trying to work with framework authors like you to fit Prisma as well as possible into your API design and ecosystem.

We're currently working towards Prisma 2 which will also include the prisma-sdk which allows you to programmatically use all Prisma features (such as DB introspection, client generation, migration system, query engine, ...) individually. Could you even decide to "hide" to the developer that Prisma is being used and come up with your own UX flows that use Prisma under the hood.

Here's an idea how the API could look like:

@ObjectType
@Prisma({
  model: 'Product',
  pick: ['id', 'name', 'type', 'brand', 'variants'],
})
export class Product {

  @Field
  options(args?: { showAll?: boolean }): Promise<Option[]> {
    return this.ctx.prisma.options()
  }

  @Mutation({ name: "setProductPrice" })
  setPrice(price: number) {
    // ...
  }

}

[MichalLytek]

@schickling

We're currently working towards Prisma 2 which will also include the prisma-sdk which allows you to programmatically use all Prisma features

That's great! SDK with programmatical way to register Prisma types and generate client, etc. would be great, as printing a prisma.datamodel file with directives is not possible with graphql-js.

Wrapping/hiding this under the decorator-based API is the simplest thing to do 😉 Can't wait to try the alpha/beta of the SDK!

[JonnyBGod]

@schickling

We're currently working towards Prisma 2 which will also include the prisma-sdk which allows you to programmatically use all Prisma features

Great news indeed.
Any information available atm on this? Like roadmap, possible to alpha/beta test, documentation and specs?

I am currently prototyping an extendable framework and I want prisma to be a prime citizen. Also considering type-graph and maybe nexus as plugin schema definition providers.
But one feature that is mandatory is to define a single schema composed of modules and use it to resolve both database and business logic schemas. And with that update Prisma with latest schema changes on the fly.

Would really appreciate at least a generic idea of when would this be possible to plan my roadmap accordingly.

Thanks.

[gotexis]

+100

Really looking forward to this. I think we shouldn't need datamodel.prisma.

Generating GraphQL types is OK and a necessity in the near future.

[FluorescentHallucinogen]

Looking forward to TypeGraphQL integration with Prisma. :eyes: I don't like the Nexus syntax.

The first preview of Prisma 2 is out. But I don’t understand how all that will fit and work together.

1. I write Prisma schema file. (I believe the correct term is _data model_, not _schema_, because it contains only models, not operations.)
2. Then I generate the JavaScript/TypeScript API using PhotonJS.
3. What's next? :thinking:

My final goal is to get the full OpenCRUD GraphQL API.

Will it possible to define the data model using TypeGraphQL's classes and decorators instead of Prisma format?

[sarthakagrawal]

My company is very excited to try out the type-graphql/prisma 2 integration. When can we expect this to be available? @19majkel94

[MichalLytek]

@sarthakagrawal
Prisma 2 release is scheduled in about 2-3 months, so this fall might be a real term of the fully working, prisma-first TypeGraphQL integration 😉

[FluorescentHallucinogen]

@19majkel94 What about my questions?

[MichalLytek]

@FluorescentHallucinogen

1. I write Prisma schema file. (I believe the correct term is _data model_, not _schema_, because it contains only models, not operations.)
2. Then I generate the JavaScript/TypeScript API using PhotonJS.
3. What's next? :thinking:

1. Step 2 also generates TypeGraphQL types and resolvers classes, using a custom typegraphql-prisma generator, that you can use and extend to enhance or limit the basic crud capabilities.

[webnoob]

Any news on this one? Really don't like nexus syntax and would love to see this in action! :)

[MichalLytek]

I have a working basic integration on a private repo 💪 Waiting for feedback from Prisma team and for some changes in the Prisma generator API to make it easier work on non-UNIX OSes 😉

[webnoob]

Sounds excellent. I'm early on in a project (prototyping) so hit me up if you need some testing done. Also, if we can poke a GitHub issue to aid you getting some feedback, let us know :)

p.s Thanks for your hard work.

[MichalLytek]

The preview of the integration is now publicly available 🎉

https://twitter.com/MichalLytek/status/1199708285622005761

Closing this issue in favor of #476 to indicate that only the new Prisma Framework (Prisma 2) will be supported 🔒