app reference modes

[prisma-labs]

app reference modes

[jasonkuhrt]

CC @Weakky

[jasonkuhrt]

Epic ~2-3h call with @Weakky about this (and more). Really good stuff. Will recap. First the outcome:

• We will start with exported singleton option.
• We will not implement other modes yet, instead getting more feedback

Now, details

• We came to the conclusion that it is premature to engineer different modes right now.

• We think there are enough friction points we're addressing, that we do not need to add our own (else engineering effort to compensate) via different modes etc.

• We noticed a problem that autocomplete for objectType enumType etc. is going to show results from nexus package. At least in vscode. A solution is a vscode plugin. For vim, sublime, ... who knows 😬. Our current app singleton approach skirts the issue, for now, but we will have to revisit this.

• We would like to get feedback from users close to the project, like Max S., Matic and a long-time DM'er to Flavian.

• We considered singleton design like:

   import app, { objectType, ... } from 'pumpkins'
  

  where objectType is alias to app.objectType.

  We decided against this because the mental model is maybe awkward. named exports that are mutating state of app. It is complicated to reason about and api does not help indicate this in any particular way. You just have to "know".

• We considered going with exported constructor.

  Benefit of singleton became clear as to looked at this option.

   import { createApp } from 'pumpkins'
  
   export const app = createApp()	
  
   app.server.start()

  Now developer has to make app available to all schema modules, and import those schema modules back

   // schema.ts
   import { app } from './app'
  
   app.objectType(...)

   + 	import './schema'
   	export const app = createApp()

  But this is a cyclic dependency which Node/CommonJS modules do not support. And TS compiles down to that. And we're assuming no .mjs for now. So this won't work. So we're forced to wrap the schema in a thunk.

   +	import { App } from 'pumpkins'
   -	import { app } from './app'
   	export default (app: App) => {
   		app.objectType(...)
   	} 

  All of this starts to make one wonder, what value do I get from just not using the pure approach of native nexus building blocks, e.g.:

   import { objectType } from 'nexus'
   export const Foo = objectType(...)

  Developer already knows that api, no cyclic dep headache...

  And there are still more issues, going back to our app.ts it is not suitable for import because it boots the server (app.server.start()). More reason to use the native nexus api. Or, user has to add something like as follows to the codebase:

   // index.ts
   import { app } from './app'
   app.server.start()

  Overall, the framework experience significantly falls apart.

• We considered global singleton

  It is very interesting, but we don't know enough yet if its going to be the right thing. We think letting users try this as a mode and getting feedback will be great.