Code-first Prisma schema API

As requested in this issue, we’re currently debating if/how we should provide a code-first API to build up a Prisma schema.

Citing the original arguments (pro code-first) from @HosseinAgha:

• Please re read your article on the problems of schema first development.
• I worry that in time you reach the same conclusion and you end up with a schema language that tries to solve everything but is not as good as a real programming language.
• I think having a real general purpose programming language at your disposal is always a good idea. (take Webpack config or many other tools for example)
• I understand that Prisma is a cross language tool (Go driver for example) but it is also written in JS and Generator and Lift need node to run. So I see no harm in having a schema.prisma.js option.

Note that a good foundation for a code-first API might be the Prisma SDK. This issue is used to discuss the possibilities and pros/cons of the approaches.

[jednano]

Please support a TypeScript, code-first schema!

Benefits of a TypeScript, code-first schema

1. The TS API parses both TS and JS files, providing a solid AST, from which a Prisma schema can be generated. You might even be able to leverage some type inference when parsing JS.
2. DRY, single source of truth.
3. Learn one language. Apply it everywhere. TypeScript all the things!
4. It’s the missing link to writing a truly full-stack TypeScript application (see above).
5. Improve confidence by generating TS definitions for client-side applications (and more).
6. We will have achieved nirvana, the ultimate state of enlightenment.

[terion-name]

I don’t like this style of definitions:

const User = objectType('User', t => {
  t.id('id')
  t.string('name', { nullable: true })
})

const Query = objectType('Query', t => {
  t.field('user', 'User', {
    args: { id: idArg() },
    resolve: (_, { id })
  })
})

It is complex, needs a lot of learning from developer, it’s not really easy readable, etc.

I loved SDL-first approach paired with Prisma and graphql-import: this allowed me to make a toolset that allows to generate resolvers over schema and spin up services with rich CRUD interface in matter of minutes after data definition.

Now with lift, photon and nexus it seems I can’t do this, and this is a big problem for migration of my toolsets to Prisma2

One thing that I think is mandatory is for photon to generate not only programmatic crud-client, but crud schema also, to make it possible to import crud definitions in application schema. This saves A TON of time, seriously