VSC extension: Adding a database-backed field

[schickling]

Perceived Problem

It's a common workflow that you want to add a field to GraphQL + Prisma schema. Right now it requires changing two files manually.

Ideas / Proposed Solution(s)

An idea would be to have a VSC-based flow to add a field to either the Prisma or the GraphQL schema and it automatically adds it to the other schema as well.

[jasonkuhrt]

How important do you think this is once graphql-nexus/nexus-plugin-prisma#299 / graphql-nexus/nexus-plugin-prisma#303 land?

This approach is a scaffolding-over-api strategy. Just noting because so far we've been aiming toward the api side. In other words, if there's boilerplate, ideally we improve the API.

However, as it stands, there is no API into the Prisma PSL so this would be the only way to automate in that direction AFAICT.

I think teaching VSCode to do this would be based upon framework capabilities. The VSCode part would be just a thin integration. Thus, we would have the potential to one day expose this feature in other places:

• terminal interactive flow
• other editors (community supported)

Scaffolding in the direction of PSL will be the easier of the two directions I think, since the conventions and language constraints are much stricter.

This makes me think we could see this as three deliverables:

• for data-layer-to-api-layer direction: work on Expose all fields with nexus-prisma v2 graphql-nexus/nexus-plugin-prisma#299 / Bring back t.prismaType on the v2 graphql-nexus/nexus-plugin-prisma#303
• for api-layer-to-data-layer direction: work on scaffolding (wonder if this will involve some Prisma SDK work, to e.g. work with the PSL AST?)
• for data-layer-to-api-layer direction (part 2): work on scaffolding

[schickling]

I agree with your thoughts. Let's work on the API part first and revisit this later. Mostly created the issue to keep track of this idea. Not a priority IMO but let's see whether this workflow/use case comes up more often.