Prisma plug-in exposing all fields

[marceloverdijk]

Would it be possible to expose all Prisma fields on an Object automatically without exposing the one by one explicitly?

[hayes]

This is probably not something that would be part of Pothos core. It could be something you could write yourself if you wanted.

There will be some utilities coming in the future (see #348) that will make building something like this your self easier.

It would be posssible to use data from the prisma client (currently prisma._dmmf, soon to be prisma._baseDmmf) to get the list if fields on a type and expose all of them. Writing a method that takes the field builder, and returns an object with all the fields would be pretty trivial (if you just use a few anys). This goes against some of the core principles behind pothos.

I strongly believe that your data and API should not be tied closely together, and the Pothos APIs try to reflect that by making the types and fields in your API be defined explicitly. A simple test for this is asking if the API would change automatically if your data source chages. In Pothos, the goal is for this to cause a type-error rather than for it to cause a change in the schema. You will notice things like the expose methods requiring the field name as well as the name of the column they are exposing even though they are often the same. Pothos also requires you to explicit define the type of the fields you are exposing. a String type in your DB could be a String in graphql, but it could also be an ID, or a custom scalar like email. When you get into exposing things automatically you take away that control, and usually end up with a lower quality API.

I recently posted a bit about plans around making crud APIs easier to build in the Pothos discord channel:

What I will likely end up releasing will probably be a compromise between being explicit, and making it very fast/easy to set up a crud API. It will likely consist of a set of composable utilities. Something along the lines of methods for building input types that map to where and orderBy that can be used when defining prisma fields, relations and connections. Helpers for defining input types for create and update would be the second layer, this would require defining which fields are included, optionally adding defaults, and probably ways to nest relations in the creates/updates. This piece will require more configuration because there are a LOT of ways that you could define nested updates/creates. Sometimes you want to connect to existing types, do deletes, updates or creates on a relation, sometimes you need to append or remove from a list, etc. Sometimes relations are required, or can be left empty, etc. create/update/delete/get/list would all be trivial to define manually once you have these input types, so the final piece would be a series of examples of how you can compose these utilities to define your own crud builders. Eg an example of creating your own method that takes a prisma type name, and maybe a few other options, and then spits out a full crud interface for that type. By providing building blocks and simple examples of how to stitch them together people can get an API that is as easy to use (once set up) as the nexus prisma plugin, but still lets users fully control how things work, and puts the "generation" piece into something defined by the app, not the framework so it's more opt in

Hope this helps.

[marceloverdijk]

Thx for reply . Just realized that I already started a discussion about some time ago 🫣 #362 so sorry for duplicate.

Anyway looking forward tintje future utility helpers a you mentioned. Is this something we can track somewhere?

[hayes]

The linked PR is the main place to track. Not much to share yet.

[marceloverdijk]

OK I will have a look.

Would be nice to be able to do something like:

builder.prismaObject('Post', {
  fields(['id', 'title', 'author'])
});

to automatically use these fields from the Prisma model incl. type + nullability.
The object can then be extended with fields not part of the Prisma model or define fields and define a different type or resolver.
Just thinking out loud.

[marceloverdijk]

I can probably use the Prisma dmmf to get models + its fields... so I will start experimenting with it soon to try to create some utilities myself as well.

[hayes]

The biggest hurtle with the API you are suggesting is figuring out the graphql types for your db fields. For example a string in your db could be a graphql string or ID, the isn't a good 1-1 mapping that works in all cases..

[marceloverdijk]

Yes indeed, mapping the Prisma db type to the correct GraphQL will be interesting..

Without having looked at the code much, I can maybe use use some defaults...
Like db text types map to string, db date types map to string or a (custom) GraphQL scalar.
And maybe primary keys could maybe map to a GraphQL ID.

builder.prismaObject('Hotel', {
  fields: (t) => ({
    ...prismaFields(
     { field: 'id', type: 'ID' },               // <= maps to GraphQL ID type
     'name',                                    // <= maps to Prisma name field auto detecting type, nullable etc
     'country',                                 // <= maps to Prisma country relation auto detecting type, nullable etc
     { field: 'latitude', type: 'Latitude' },   // <= maps to Prisma latitude field (double) but overrides GraphQL type
     { field: 'longitude', type: 'Longitude' }, // <= maps to Prisma longitude field (double) but overrides GraphQL type
    ),
    tags: t.stringList({
      resolve: (parent) =>
        parent.tags ? parent.tags.split(',') : [],
    }),
    hello: t.string({
      args: {
        name: t.arg.string(),
      },
      resolve: (parent, { name }) => `hello, ${name || 'World'}`,
    }),
  })
})

Does it make sense?

Maybe I should be able to pass the tags and hello fields also to the prismaFields helper to allow full sorting of the fields inside the GraphQL object... in the current example I cannot define e.g. tags below the name field to group related fields.

[kleydon]

This feature would be extraordinarily helpful in early prototyping/development; perhaps enabled/gated by some sort of default-to-all-fields-exposed vs default-to-all-fields-hidden flag (with the ability to provide a list of fields that don't adhere to the default behavior).