[Question] Prisma + Interfaces?

[erandagan]

Assume you have a domain that is modeled like so:

   +-------+
   | Media |
   +-------+
     /   \
    /     \
+-------+ +-------+
| Movie | | Show  |
+-------+ +-------+

Media is solely an API concept—Internally, Movie and Show are 2 separate tables, and there is no table that connects all of them to a single collection. So, with that in mind, we create the Media interface:

class Media { 
  title: string;
  poster: Poster; // defined elsewhere
  type: MediaType; // MOVIE | SHOW | ...
  ...
}

And then have both Movie and Show implement that interface:

builder.prismaObject("Movie", {
    interfaces: ["Media"], // Raises a TS error
    fields: (t) => ({
      title: t.exposeString("title", { nullable:false })
      type: t.field({
        type: MediaType,
        nullable: false,
        resolve: () => MediaType.MOVIE,
      }),
      poster: t.field({
        type: Poster,
        nullable: true,
        select: { poster: true, posterThumb: true },
        resolve: (movie) =>
          movie.poster && movie.posterThumb
            ? new MediaPoster(posters.url(movie.poster), movie.posterThumb)
            : null,
      }),
   })
  }
)

(Similar implementation on Show).

In this point, we already get a TS error saying the object shape must extend the interface - even though we have everything defined properly. If we ignore the error and run the code as-is, it still works, so let's try to move on for now.

We now have a query field on the type User called followedMedia, which queries the items the user follows. Let's define it in a naive way—

builder.prismaObject("User", {
    fields: (t) => ({
      followedMedia: t.field({
        type: ["Media"],
        nullable: false,
        select: {
          followedMovies: {
            select: {
              movie: true,
            },
          },
          followedShows: {
            select: {
              show: true,
            },
          },
        },
        resolve: async (user) => {
          return [
            ...user.followedMovies.map((f) => f.movie),
            ...user.followedShows.map((f) => f.show)),
          ];
        },
      })

But this raises a new error - the returned type, which is plain Prisma result objects, does not match the Media type.

Makes sense - we couldn't really expect this to work as-is, but the docs don't mention how we can tackle this use-case.

1. We can't use prismaField, which handles the mapping of the returned type to the GQL type, since the GQL type is a custom interface.
2. We can't wrap the returned items in a new Movie(f.movie) or new Show(f.show) since those types are internally generated by Pothos (so this only works for plain objects)
3. We don't want to manually convert each item to be Media compatible, since we'll repeat the logic that already exists in the Movie type resolver itself (for instance, converting the poster and posterThumb fields into a single Poster object)

So I'm wondering, what are the options here?

[hayes]

The general rule for interfaces is that object types need to by type-compatible with the type defined for an interface. Using a class for your interface is probably a bad starting place.

What you can do is use a simpler interface type that only contains the common properties of the 2 tables

interface Media {
  title: string
}

const Media = builder.interfaceRef<Media>('Media')
Media.implement({
  fields: (t) => ({
    title: t.exposeString('title'),
    poster: t.field({
        type: Poster,
        nullable: true,
        // since we aren't defining a resolver here, movie and show need to implement the poster field as well
    }),
  })
})

const Movie = builder.prismaObject("Movie", {
    interfaces: ["Media"], // Raises a TS error
    fields: (t) => ({
      poster: t.field({
        type: Poster,
        nullable: true,
        select: { poster: true, posterThumb: true },
        resolve: (movie) =>
          movie.poster && movie.posterThumb
            ? new MediaPoster(posters.url(movie.poster), movie.posterThumb)
            : null,
      }),
   })
  }
)

builder.prismaObject("User", {
    fields: (t) => ({
      followedMedia: t.field({
        type: [Media],
        nullable: false,
        select: {
          followedMovies: {
            select: {
              movie: true,
            },
          },
          followedShows: {
            select: {
              show: true,
            },
          },
        },
        resolve: async (user) => {
          return [
            // Adding brands will allow pothos to automatically determine the type during resolution
            ...Movie.addBrand(user.followedMovies),
            ...Show.addBrand(user.followedShows),
          ];
        },
      })

I've removed the type, because you can just query for __typename, but if you wanted to add the type, you are probably better off doing something similar to poster where its defined without a resolver on the interface (and not included in the type for the interface, and then you add the field definition with a resolver on each type that implements Media

[erandagan]

@hayes Thank you for the clarification. This does seem to help, but Pothos still complains about Movie not implementing Media.

The problem seems to happen when an implementation of Media defines a field through .field instead of .expose - if I change Media to only require primitive fields that are exposed, the type check passes. However, if one of the fields is defined via .field, Pothos complains about it. In your example, Poster still raises an error.

Simplified example using a primitive field:

export interface Media {
  id: number | string;
  title: string;
  isFollowed: boolean; // Resolved by children
}
...
Media.implement({
    fields: (t) => ({
      id: t.exposeID("id", { nullable: false }),
      title: t.exposeString("title", { nullable: false }),
      isFollowed: t.exposeBoolean("isFollowed", { nullable: false }), // Also tried `t.boolean` here
    }),
  })

  const movieType = builder.prismaObject("Movie", {
    interfaces: [Media], // Error!
    fields: (t) => ({
      // Other fields...
      isFollowed: t.boolean({
        nullable: false,
        select: (_, ctx) => ({
          followers: {
            where: {
              userId: ctx.userId,
            },
            select: {
              id: true,
            },
          },
        }),
        resolve: (movie) => movie.followers.length > 0,
      }),
    }),
  });

In this example, the isFollowed field is resolved, not exposed, and type check fails.

[hayes]

The typescript type/interface describes the data returned by your resolvers and what is available on the parent object.

If you add isFollowed to the interface, all the types that implement Media need to have that property (which they don't)

If the parent object (eg. the movie row from the db) doesn't have the isFollowed property, you can't "expose" it because it doesn't exist.

You can use normal field methods without a resolver to define the field on the interface. This implements it with a default resolver that just throws an error.

When you add an isFollowed field on types that implement Media you are overwriting that default resolver, so it won't throw for those types.

Just removing the isFollowed property from the typescript type, and using t.boolean instead of t.exposeBoolean should be all you need:

export interface Media {
  id: number | string;
  title: string;
}
...
Media.implement({
    fields: (t) => ({
      id: t.exposeID("id", { nullable: false }),
      title: t.exposeString("title", { nullable: false }),
      isFollowed: t.boolean({ nullable: false }),
    }),
  })

  const movieType = builder.prismaObject("Movie", {
    interfaces: [Media], // Error!
    fields: (t) => ({
      // Other fields...
      isFollowed: t.boolean({
        nullable: false,
        select: (_, ctx) => ({
          followers: {
            where: {
              userId: ctx.userId,
            },
            select: {
              id: true,
            },
          },
        }),
        resolve: (movie) => movie.followers.length > 0,
      }),
    }),
  });