Is there a way to deactivate massively the create input (I only want the connect one) in all the mutations with prisma or nexus? I know how do it, but one by one with nexus, filtering this property but I would like to know if exists some way to do it massively.

why would you want to do this?

this worked for me

export const Mutation = prismaObjectType({
  name: 'Mutation',

  definition(t) {
    t.prismaFields(['*']);
    t.field('signup', {
      type: 'AuthPayload',
      args: {
        name: stringArg({ nullable: true }),
        email: stringArg(),
        password: stringArg(),
      },
      resolve: async (parent, { name, email, password }, ctx) => {
        const hashedPassword = await hash(password, 10);
        const user = await ctx.prisma.createUser({
          name,
          email,
          password: hashedPassword,
        });
        return {
          token: sign({ userId: user.id }, APP_SECRET),
 
          user,
        };
      },

});

I'm using a proxy before of prisma server, and in this proxy I'm hiding some mutations, but if I'm creating a entity, I don't want to allow to create a new nested entity, I would like users use main mutation to do it, only allow to link with an existent nested entity.

you are forwarding mutations directly from the user to prisma

@Jorge here you only has extending the mutations with a custom one, I'm talking about hide some properties in all the inputs.

at least I get the use case

It's a main proxy, not a bad idea for us because this proxy includes 3 or 4 schemas of different servers.

you mean schema stitching

Yes

just seems dangerous to let end users run prisma mutations directly

In this proxy we have the auth part analyzing his bearer

right... you are basically calling graphql yoga a proxy

exactly

right, pretty much everyone using prisma uses an apollo server

Yes, don't worry about that 😄

seems like someone who knew how prisma worked could really mess with your data, I dunno

I analize individual claims to know what the user can execute or not

so you are creating an API on top of prisma... which is the norm

Prisma server will not be public, only apollo server

yea I get that

No no..

since you have a schema on top anyways

Because I do a executable schema and I expose it directly, but analyzing the permissions, and I'm hiding some mutations (e.g. main entities) and these inputs that I want to hide too, are about these main entities.

so you do expose prisma to the end user

Hi @Martí Crespí out of curiosity are you stitchingwith

graphql-tools

? I created this issue/question to see how people do that with nexus: https://github.com/prisma/nexus/issues/70 At which point do you analyse those claims @Martí Crespí? Did you create another graphql server on which you do that?

Hi @Uby, yes I'm stitching with graphql-tools, and then I'm serving it with apollo server. And before to send the operation to sub servers, I analize the claims with an apollo link allowing or denying the current operation.

I am doing something similar for an admin application, but for the public application I am putting another graphql server in between my stitched one and the client. So that like @CCBCodeMonkey said you don’t let someone being able to introspect and see all you can do on your backend.

Right, it's as you're saying.. Perfect! I will take a look at these links! Many thanks!