Code First Approach with Nexus-Prisma

[marcjulian]

I'm submitting a...

[ ] Regression 
[ ] Bug report
[x] Feature request
[ ] Documentation issue or request
[ ] Support request => Please do not submit support request here, instead post your question on Stack Overflow.

Current behavior

Nestjs Graphql uses the "Schema-First" approach to define the Graphql Api. Prisma and Prisma-Client can be used in connection with Nestjs to build the Graphql Api.

Expected behavior

Nestjs Graphql can use the "Resolver/Code-First" approach to define the Graphql Api.
Prisma released the nexus-prisma plugin to generate the Graphql Schema based on the implemented resolvers using the prisma-client under the hood and inside the resolvers. Furthermore, it is compatible with e.g. apollo-server.

Minimal reproduction of the problem with instructions

I created a project with nestjs, prisma-client and nexus-prisma. You can find it here https://github.com/marcjulian/nestjs-prisma-nexus. The Schema generation with nexus-prisma works for exposing and hiding queries and fields. However, I couldn't add a custom query using Nestjs Resolver and Query.

The Schema is setup inside GraphqlConfigService located in src/prisma.

Here is an example:

I am exposing all queries from the prisma api to the nestjs api and I am adding a custom helloWorld query.

const Query = prismaObjectType({
            name: 'Query',
            definition(t) {
                t.prismaFields(['*'])

                t.field('helloWorld', {
                    type: 'String',
                    resolve: (_, { id }, ctx) =>{
                        return 'Hello World'
                    }
                });
            }
        });

You can call the query from the Nestjs Playground and you receive Hello World.

Instead of defining the custom query inside of GraphqlConfigService I would like to use a resolver for example AppResolver:

@Resolver()
export class AppResolver {

    constructor() {

    }

    @Query()
    helloWorld() {
        return 'Hello World!';
    }
}

The approach with the Resolver doesn't work because nexus-prisma doesn't know about the custom Query. How can I use a Query inside a Resolver and use nexus-prisma to generate the custom query to the Graphql Schema?

What is the motivation / use case for changing the behavior?

The motivation to use Resolver and Query, Mutation and Subscription is to use the existing features of Nestjs such as guards andinterceptors.

Environment

Nest version: X.Y.Z

 
For Tooling issues:
- Node version: XX  
- Platform:  

Others:

[tanekim88]

On top of this feature, support for CQRS (with Sagas) + Nexus Prisma to be working together would be incredible. Example code would be highly appreciated.

[kamilmysliwiec]

Isn't Nest 6.0.0 code first approach (with type-graphql) cleaner than this? See https://docs.nestjs.com/graphql/resolvers-map#code-first

[tanekim88]

With nexus-prisma, we can first create schema with sdl, and then we can extend/override/modify its methods and fields properties using typescripts, just like the schema first approach in your documentation.

Types generated from sdl using 'prisma deploy' command give a lot of free methods. For example, if I created type User{} in sdl, it would create 'createUser', 'deleteUser', 'updateUser', and many many other methods that are functional in graphql playground.

However, unfortunately, we are not allowed to add type Query{} or type Mutation{} in datamodel.prisma file (in prisma documentation), because 'prisma deploy' commands will generate them for us and create final version of graphql type file that will be used in graphql, and we adding them instead manually will cause duplicate type error during ' prisma deploy' due to conflict with generated types.

So, schema approach documentation in nests's graphql section cannot be done when used with prisma.
It would be awesome if you can create framework that can make this work together smoothly.

[kamilmysliwiec]

There is no bandwidth to support nexus-prisma

[marcjulian]

Sorry for my late reply. Yes the code first approach of 6.0.0 with type-graphql is much cleaner. I like the concept of decorators.

[VienNguyen113]

@kamilmysliwiec with nexus-prisma we can easily expose prisma generated query+mutation instead of using prisma-binding

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.