Yes, I also like this decision

Yes, the desicion is great. Focus on schema is more important than on server (framework) where everybody has different needs. Hope this will keep for a long time (focus on @nexus/schema)…

I've been using Yoga for my GQL server. It was going to be replaced by Nexus framework. Now that that is no longer a thing - which I'm totally fine with - what server(s) do people find works best for them since Yoga isn't really supported anymore?

after following the conversion guide back to schema, I cant seem to get the nexus & prisma plugin typings generated anymore, they are supposed to default output to @typings right? and should be generated when running ts-node on the schema.ts file?

If you have an object defined as follows:

const Post = objectType({

  

name: 'Post',

 

definition(t) {

<http://t.int|t.int>('id')

  

t.string('title')

 

},

})

@jasonkuhrt do we have any roadmap defined for @nexus/schema? My recommendation would be to 1. simplify bootstrapping configuration 2. support federation support with apollo 3. support for golang and other languages defined in prisma roadmap. This helps to define purpose more cleanly (enabling graphql APIs). It keeps it more aligned with prisma roadmap on language support and so the overall commercial cloud offering. We are living in a polyglot micro service world. It would be imperative for prisma to support multi language to sustain longer.

@jasonkuhrt I really loved the hooking system of nexus where you could hook into the lifecycles of dev or build and run code between them. Now with nexus disappearing is there a recommended approach/server/library to archive that ? For now Iam looking to get: dev -> onStart, onFileChange and build -> onStart going. I guess some way of combining AS2 + chokidar would do it right? Looking forward with help on this

I use

t.connection

previously when using nexus, so I need to write all the type definitions by myself I suppose…. or does nexus/schema supports it? seems not?

If I add a resolver field to my prismaObjectType - is it possible to include that field in the WhereInput somehow? When I generate new code, I still only see the fields that exist in my datamodel/database. I run Nexus 0.11.7 and Prisma 1.34

Now the prisma/client is a peer dep of nexus-prisma-plugin which is super good, no need to wait for catching up with Prisma ver, but why a static ver? So the nexus-prisma-plugin still need to work with a specific version of Prisma?

Am I missing something or have nested upserts disappeared?! I just transitioned back to schema from framework and I used to be able to

upsert

a relation field when `create`ing.

Is there any way of overwriting the default resolvers when implementing an interface? Apparently there was a t.modify api that helped with this but its been deprecated

interface resolvers shouldnt even be a thing tbh

Hi A few months ago I use the nexus framework to setup a server. Currently is hard to find documentation. Something was change and nexus server are deprecated? Which server I should use now?

Following the example from here: https://nexusjs.org/docs/adoption-guides/neuxs-framework-prisma-users#configuring-custom-scalars Does anyone know why I might get this error:

Missing type Json, did you forget to import a type to the root query?

Is there any way to run nexus under SSL? This is how I'm currently setting up nexus, but there doesn't seem to be any settings to change this

import app, { server, settings } from "nexus";

app.on.start(() => {})

settings.change({
  server: {
    host: '<http://192.168.1.10>',
    port: 4000,
    path: '/',
  },
})

app.assemble();

so i'm running into an issue with a custom input type that i cannot figure out... i have an input like this:

export const CreateSelectionInput = inputObjectType({
  name: 'CreateSelectionInput',
  definition(t) {
    t.string('labelVersionId', { required: true });
    t.string('name', { required: false });
    t.list.string('elementIds', { nullable: false });
    t.string('componentIds', { list: true, required: false });
    t.field('bounds', { type: GeoJsonPolygonInput, required: false });
  },
});

you'll notice i'm experimenting with a few different options with

elementIds

and

componentIds

. this config above generates the following sdl:

input CreateSelectionInput {
  bounds: GeoJsonPolygonInput
  componentIds: [String]
  elementIds: [String]!
  labelVersionId: String!
  name: String
}

you'however, i can't seem to figure out the correct configuration to get the following sdl:

input CreateSelectionInput {
  bounds: GeoJsonPolygonInput
  componentIds: [String!]
  elementIds: [String!]
  labelVersionId: String!
  name: String
}

essentially, i want to have an optional list of non-nullable strings (

elementIds

and

componentIds

). i can't seem to find any examples of this online.

t.list.string('tagIds')

will give me a GraphQL type like

tagIds: [String]

,

t.list.string('tagIds',{required:true})

results in

tagIds:[String]!

how could i get a type like this:

tagIds: [String!]

Where I could read something about security rules or performance practice. In nexus docs I saw only this page https://nexusjs.org/docs/guides/best-practices I thinking most on looping quere request if I return some full object type.

is there anyway to setup the

auth

header for the apollo playground requests?

I have some models where graphql inputs are not generated properly. I need input

UserCreateInput

but there’s only

UserCreateWithoutPostsInput

. What decides whether the plain input is generated or not ?

got this problem when build, what i did wrong here? I am using Apollo server + nexus/schema + nexus-prisma-plugin combo > node_modules/@types/typegen-nexus-plugin-prisma/index.d.ts126 - error TS2307: Cannot find module ‘nexus-plugin-prisma/typegen’ or its corresponding type declarations.

When deploying to Heroku i got this error:

remote: Type error: Property 'model' does not exist on type 'ObjectDefinitionBlock<"User">'.
remote: 
remote:   19 |   name: 'User',
remote:   20 |   definition(t) {
remote: > 21 |     t.model.id()
remote:      |       ^

Maybe this connected with @nexus/schema or nexus-plugin-prisma?

"nexus-plugin-prisma": "^0.19.0",
"@nexus/schema": "^0.16.0",

using nexus schema, do I need to export mutations and add them to types key of makeSchema? They don’t appear in playground until I do it. I thought

extendType({
  type: 'Mutation',
  definition(t) {
    t.field('sendMessage', {
      type: 'Message',

was enough

In my schema I have a

Project

that is related to an

Organization

I would like to

createOneProject

by just specifying teh organization ID but it generates as requiring the whole

organization

object.

//Simplified
model Organization {
  id        Int        @id @default(autoincrement())
  name      String?
  projects  Project[]
}

model Project {
  id          Int       @id @default(autoincrement())
  organization Organization @relation(fields: [organizationId], references: [id])
  organizationId Int
  name        String
}

I'm using the

experimentalCRUD

to generate

createOneProject

but it auto generates with

type Mutation {
createOneProject(data: ProjectCreateInput!): Project!
}

Where

type Project {
  id: Int!
  name: String!
  organizationId: Int!
}

input ProjectCreateInput {
  name: String!
  organization: OrganizationCreateOneWithoutProjectsInput!
}

can I remove

organization Organization @relation(fields: [organizationId], references: [id])

from the

Project

in

schema.prisma

? so that I only have the

organizationId

field? Or would I lose that relation?

nvmd figured out this whole

connect

function

Hello there 🙂 little question about

@nexus/schema

. If you look at

outputs.typegen

typedoc in SchemaConfig (makeSchema function param) it says "Set to true to enable and emit into default path ... The default path is node_modules/@types/nexus-typegen/index.d.ts." but if I set the value to

true

instead of a path (like

___dirname +_ '/../node_modules/@types/nexus-typegen/index.d.ts'

), it generates nothing. I am doing something wrong or is it normal ?

@jasonkuhrt it'd be interesting if we could pass in the TS type to a field definition that will override the scalar's type, ex:

objectType({
  name: 'User',
  definition: t => {
      t.id<UserId>('id')
  }
})

this is interesting when youre using nominal types, which is something might be builtin to TS one day https://github.com/microsoft/TypeScript/issues/202#issuecomment-695912785