Hey guys, having an issue I hope someone can point out where I’ve gone wrong. I have 2 simple queries that are somehow taking between 10-20 seconds to resolve and return the payload back to the user. All the logic in the resolver finishes nearly instantly, but somewhere between returning the data in the resolver and the end user there is 10-20 seconds of time being eaten somewhere that I can’t discern. This issue is only seen when the app is deployed online, locally this issue doesn’t exist. As far as I can tell by all my server metrics, nothing is peaking or overloading… and the data being worked with is very simple and small - nothing that would stress a database/cpu. Any suggestions?

I'm currently removing nexus-plugin-prisma and I can't seem to find an alternative for

originalResolve

where I can check for validity within the

resolve

function and either return

originalResolve

if it's valid or some default value if not. What to do?

I'm in the process of removing

nexus-plugin-prisma

and trying to determine if I am on the right track/looking for some suggestions. We have a fairly large highly relational schema, ~110 models and ~35 enums. We had our resolvers split up into separate files per model. So my method has been to go through each resolver file, convert based on the documentation (which has been very helpful!) and add input types as necessary. Basically, convert

objects

,

queries

and

mutations

by plucking them straight from the sdl converter and then add the specific

inputTypes

that are required. This has been working well except for one issue...because we have so many models and they are highly relational, there are a TON of

inputTypes

that we seemingly need. I'm trying to find a sane convention for splitting these up into manageable chunks, but on some of our larger models with a lot of relationships we can have up to ~40k lines of

inputTypes

🤯 so 2 questions: 1. Is there something I am just completely missing as far as adding

inputTypes

when doing the conversion? 2. Any suggestions for organizing the inputTypes into manageable chunks? a. so far I have split them into folders by model and then files by

create

update

upsert

where

orderBy

but on the larger models the

create

and

update

files are still close to 20k lines b. My next thought is to start splitting them further by relationship, so instead of just

model-a-create-inputs.ts

have

model-a-model-b-create-inputs.ts

,

model-a-model-c-create-inputs.ts

etc...

Some questions regarding how graphql-nexus NexusAcceptedTypeDef works internally 1. Using a ts script that traverses the prisma schema and builds the NexusAcceptedTypeDef, objectType, enumType, inputObjectType etc. So i can do some validation and remove unneeded/duplicate fields, reverse prisma create/upgrade/upsert types to use plain model fields instead of relationships field for mutations. • The issue that I'm facing is when the NexusAcceptedTypeDef has been fully build • I'm trying to serialize that object to string, is there a internal tool or types so i can fully reverse them. In a way i want instead of this ◦

{ name: 'SomeModelCreateNestedOneWithoutAttachmentsInput', definition: [Function: definition] }

• for a given type i want to get something like this

inputObjectType({ 
    name: [type-name], 
    definition(t) { 
       t.[is-this-field-nullable].[is-this-field-list-type].[type]([type-name]),//descriptions etc } })

2. Is there a performance difference when doing this a. t.nonNull.field('id', { type: 'Int' }) versus t.nonNull.int('id')

Are the args supposed to be typed?

import { idArg, mutationField } from 'nexus';
import { withAuth } from '../../utils/auth';

export const updateUser = mutationField('updateUser', {
  type: 'User',
  args: {
    id: idArg(),
  },
  authorize: withAuth,
  async resolve(_parent, { id }, { res }) {},
});

Here,

id

(and anything else I add) all have type of

any

. I'm pretty sure I have set up the types properly, because the

type: "User"

autofills with no issue

I notice this with every mutation that I have

do you have something running to generate the types?

Yep

It generates a nexus.ts and schema.graphql file

And im relatively certain the types are working because as you can see,

User

which is a custom type shows up

Hi, is the

nexus-prisma

package not able to resolve relations with a composite unique id? This part in specific:

products {
  id
  name
  productTags {
    tags {
      id
      imageURL
    }
  }
}

Results in:

"message": "Unable to resolve a unique identifier for the Prisma model: ProductTag",

model ProductTag {
  productId  Int      @map("product_id") @db.UnsignedInt
  tagId      Int      @map("tag_id") @db.UnsignedInt
  products   Product  @relation(fields: [productId], references: [id])
  tags       Tag      @relation(fields: [tagId], references: [id])

  @@id([productId, tagId])
  @@index([productId], name: "products_tags_product_id_foreign")
  @@index([tagId], name: "products_tags_tag_id_foreign")
  @@map("products_tags")
}

export const productTag = objectType({
  name: ProductTag.$name,
  description: ProductTag.$description,
  definition(t) {
    t.field(ProductTag.tags)
  },
})

Basically a many to many relation

Any idea why my next.js build could be failing?

Hello again 😅 I am trying to work around the many-to-many limitation of the new nexus-prisma library so I fetched tags manually like below but it takes

8.52s

to execute because of this, is there a way I can optimise?

export const Product = objectType({
  name: _Product.$name,
  description: _Product.$description,
  definition(t) {
    t.field(_Product.id)
    t.field(_Product.name)
    t.field(_Product.description)
    t.field(_Product.imageURL)
    t.field("tags", {
      type: list("Tag"),
      async resolve(parent, _, ctx) {
        const productTags = await ctx.prisma.productTag.findMany({
          where: {
            productId: parent.id,
          },
          include: {
            tags: true,
          },
        })

        return productTags.map((pt) => pt.tags)
      },
    })
  },
})

Hey! I don't understand how nexus handles relational data, because when I run this in a query resolver it still returns all visits regardless of their status = "completed"

resolve: async (_parent, args, context: Context) => {
  return await context.prisma.customer.findFirst({ where: { id: 11 }, include: { visits: { where: { status: "completed" } } } })
}

When I console.log it, it only returns the ones I want, that makes me confused about how the relational data is resolved, since it apparently ignores the ones returned in the resolver?

I got this interesting comment in my notifications https://github.com/graphql-nexus/nexus-plugin-prisma/issues/1039#issuecomment-909142584

I just gave it a try and it seems to me like you can “have your

.crud

and eat it too“ by just having both

@kenchi/nexus-plugin-prisma

and

nexus-prisma

as dependencies in package.json. Their respective configuration and build-time behavior don't appear to interfere with each other, and you can do

t.field()

in your `objectType`s and

t.crud.User()

in your `queryType`s.

What are your thoughts on this?

Hi. I’m utterly confused by the whole nexus / prisma relation. I’m about to upgrade from Prisma 1.34 to 2 (well… 3) and reading the migration guide lets me know that I should use nexus-plugin-prisma which then lets me know it’s been deprecated… The new nexus-prisma is still early and is not recommended to be used in production…. Is it possible to use Prisma 3.0.1 in any stable way with nexus? Or should I skip nexus entirely and write everything it does the vanilla way? I would highly appreciate some guidance here if possible 🙏🏼

Hello, anyone know of a package or tool to autogenerate graphql Input types based on a typescript class/interface, prisma model, GraphQL SDL or programmatically?

Howdy! I’ve successfully launched a very simple api with mongo+prisma2+nexus-prisma plugin+custom helpers to convert nexus-prisma output to nexus type definitions. So far so good. Now I want to add a general

where

query arg to my list field, and I really don’t want to type it manually. Has anyone any examples how you define such stuff?

as a big fan of the granular control conferred when using the @graphql-codegen/* ecosystem, it has me wondering, can you use codegen with prisma if additional outputs are desired? are there any use-case examples or example repos of someone using graphql codegen with prisma or prisma-nexus? I usually use it with headless CMSs in Nextjs, anywhere from 5-10 packages depending on project stack thanks!

Hello, I am a bit stuck on structuring something, I have a Product object type and now I want to add a query to fetch product options categories and products under that category but I should be able to query that with the product id only, am I looking for extendType or queryField here? 😅 And maybe even a new object type?

Hm after thinking about it I think I should add those fields to the Product object type and create a query to get a single product

A dumb question. What are the best practices regarding securing Prisma apis exposed in a CRUD way, e.g. via Pal.js. E.g. I have a collection

posts

to which users are allowed to append posts. This collection has a relation to collection

users

, in which users are not supposed to be allowed to make any modifications. How do I secure

users

from all the dangerous things inside

PostCreateInput

, e.g.

{data: {user: {create: {name: “You’ve been hacked”}}}}

? By manually checking all the

data.user.create || data.user.connectOrCreate

and throwing? Is there some sort of more declarative way to do this? How you people are handling this? Basically I’m looking for some declarative layer for security, e.g. saying “these dudes are not allowed to modify this collection”, and probably it has to be somewhere on Prisma side.

question about using

nexus.tsconfig.json

instead of

tsconfig.nexus.json

TS Intellisense doesn't pick up on the file when named the former but it does when named the latter why do example repos/other repos use the former if TS isn't detecting it as a tsconfig.json file? is there some abstraction layer under the hood parsing happening?

also on the topic of strongly typed context with Nextjs and Apollo Micro Server + Prisma-Nexus, just to see if my thinking is correct (first time setting up this config -- using it as a scaffold to build a CRM to replace HubSpot for my employer) Conceptually what's happening is NextApiRequest is requesting the body of

global.prisma || new PrismaClient()

as typeof Context, then on success it's appended to the previewData body of the ensuing NextApiResponse

res

before the PrismaClient is ultimately returned as Promise wrapped Context? Thoughts?

hi, we have a situation where we’re trying trying to make certain expensive fields on our objectType lazy. however, we also want to have other fields resolve based on the output of those expensive fields. for example, if we want to have a field called “fullName” that concatenates “firstName” and “lastName” fields, we can’t seem to access the first and last name fields from the root type if they contain custom resolvers.

Hello, is there a quick/convenient way to “clone” a objectType definition in order to then extend it?

I want to create a second version of an object with additional fields ie.

Image

&

ImageExtended

Bonus question - does

extendType

work with types other than ’Query`?

Does anyone know if nexus-prisma has been tested on Prisma 3.x yet? Docs says 2.30.x