hi all, i'm doing a talk at https://www.gotochgo.com on monday (https://gotochgo.com/2019/sessions/917) and it will feature prisma as part of my api layer. my use case is to consume and cache playlists, artists, albums and tracks from the spotify api (https://developer.spotify.com/documentation/web-api/reference/artists/get-artist/). each of the objects in the spotify api use 22-character unique identifiers as ids. in an ideal world, it would be much simpler to use this string directly as a type id, but prisma only supports

ID!

,

UUID!

and

Int!

types for ids. this results in mappings that look like this:

type Artist {
  id: ID! @id @unique # Generated by Prisma
  artist_id: String! @unique # From Spotify
  uri: String @unique
  href: String @unique
  genres: [Genre]! @relation(name: "ArtistToGenre")
  ...
}

It's manageable but a little noisy as i know have two "identifiers" in the prisma-exposed API. If I want to expose this API to the public, I worry this redundancy could be confusing for consumers (unless I use something nexus to omit the prisma-internal IDs from the public API programmatically). in case it comes up in Q&A after my talk, i was curious about the motivation for not allowing

String

types as IDs. It seems there are quite a variety of use cases where Prisma might be used for a read-side abstraction of an existing data model or data set that has varchars as natural unique identifiers already.