7 ms·
I wouldn't decode them like this, it's fragile, and global node IDs are supposed to be opaque in GraphQL. I see that GitHub exposes a `databaseId` field on man
by siralonso 8mo ago
I wouldn't decode them like this, it's fragile, and global node IDs are supposed to be opaque in GraphQL.
I see that GitHub exposes a `databaseId` field on many of their types (like PullRequest) - is that what you're looking for? [1]
Most GraphQL APIs that serve objects that implement the Node interface just base-64-encode the type name and the database ID, but I definitely wouldn't rely on that always being the case. You can read more about global IDs in GraphQL in the spec in [2].
[1] https://docs.github.com/en/graphql/reference/objects#pullrequest https://docs.github.com/en/graphql/reference/objects#pullreq...
[2] https://graphql.org/learn/global-object-identification/ https://graphql.org/learn/global-object-identification/
- siralonso 8mo agoAlso, as pointed out below, Github's GraphQL types also include fields like `permalink` and `url` (and interfaces like `UniformResourceLocatable`) that probably save you from needing to construct it yourself.
- catlifeonmars 8mo agoIf you want to store metadata in identifiers, an easy fix to preventing users from depending on arbitrary characteristics is to encrypt the data. You see this a lot with pagination tokens.
- tracker1 8mo ago+1, these type of behaviors are really likely to change/break in time. There's a reason the API tends to include permalink URLs... new Id's and the link pattern may very well change dramatically over time.