Question: What's a good way to have Object identification Id without saving the typename to database?

[muhajirdev]

hey @orta awesome works

I see that in this repo you're saving cuid:typename into database. If a database is already using int autoincrement. This won't work, because we cannot put string to an Int

I know we can base64 id:typename it in each mutation and resolver, before we give the id to prisma. But this would be very verbose. Is there a good way to

• when the id arrive in mutation resolver. It's already in a Int format (not base64) so
• when the id arrive in Query resolver. It's already in an Int format
• when the id arrive in the client (relay) it's in base64 (id:typename)

One possible way is probably by writng an envelop plugin. I am going to explore envelop.dev. Just curious if you have any opinion about this problem

Another thing I am thinking is that maybe ID scalar can do serialiaze and deserialize. in serialize we can encode it and in deserialize we can decode it. But not sure where I can read more about this

[orta]

You probably want to use a different field than id for your global UUIDs - it could be as simple as uid which is just ${id}:[model-type] - see nodeInterfaceIdField in the compiler settings: https://github.com/facebook/relay/tree/main/packages/relay-compiler#configuration

[muhajirdev]

Interesting approach, thanks for the insight.

Actually, what’s the standard practice for graphql object identification. Do people usually put the node id inside database model, alongside the real primary key?

Or the node is usually computed on every request via base64(typename:id)? I saw pothos graphql doing this

I’ve been googling around since last week, did not find a good resource.

How do you guys do it at artsy?

[orta]

An my app today, the node id is the primary key, incremental ints aren't a great db strategy (because you can't shard your db) and so what you see in the prisma is how I build for prod.

it depends on your db you have a mogodb for example all ids can be uuids, you just need to have it unique across your schema which in the future could also incorporate more than one API for example

In your case, a _id could be defined in the redwood service layer as just taking the existing id - then new model types could have a real _id pretty easily.

At Artsy we did:

# An object with a Globally Unique ID
interface Node {
  # The ID of the object.
  __id: ID!
}

Where an __id was generally a base64 of id:api-service:type if I recall - https://github.com/artsy/metaphysics/blob/6439278795f6a15a1217c9baf42791c17eff76ec/src/schema/v2/object_identification.ts is the source of truth but it's pretty abstract

[muhajirdev]

re: incremental ints aren't a great

interesting, I just read about cursor-based pagination. that it needs a unique and serial column. (which is the nature of auto increment). While cuid / and uuid are generally not sequential (not sortable). So, it's a tradeofff? auto increment will be faster for reading. But cuid & uuid will be better for writingn in distributed environment?

Or do you think there's an approach that can take advantage of both solution? -> Unique and serial, but also easy to shard later on?

• Would it be possible to make cuid be sortable, so the performance will be good for cursor based pagination I know we can use something like Twitter snowflake, but this is a bit overkill for my current need I think?

Thanks again for the idea & reference, very helpful

[orta]

You need a stable sort, not a sortable identifier - just a different frame of reference. createdAt on a model is usually my goto there (or something specific to the query)- but no cuids couldn't be sortable