Hyrums law at its finest :D (or D: if you deeply care about correctness)
Every GitHub object has two IDs
61–70 of 76 posts
Re: Every GitHub object has two IDs
#62> GitHub's migration guide tells developers to treat the new IDs as opaque strings and treat them as references. However it was clear that there was some underlying structure to these IDs as we just saw with the bitmasking Great, so now GitHub can't change the structure of their IDs without breaking this person's code. The lesson is that if you're designing an API and want an ID to be opaque you have to literally enc…
I think more important than worrying about people treating an opaque value as structured data, is wondering _why_ they're doing so. In the case of this blog post, all they wanted to do was construct a URL, which required the integer database ID. Just make sure you expose what people need, so they don't need to go digging. Other than that, I agree with what others are saying. If people rely on some undocumented aspect…
GitHub actually do have both the database ID and URL available in the API:
https://docs.github.com/en/graphql/reference/objects#pullreq...
OP’s requirements changed and they hadn’t stored them during their crawl
Re: Every GitHub object has two IDs
#63I remember a time when the v3 API didn't even have IDs and whenever someone in your org changed their username or renamed a repo you'd be left guessing who it is. This is also the reason I wrote our current user onboarding / repo management code from scratch, because the terraform provider sucks and without any management you'll have a wave of "x got offboarded but they were the only admin on this repo" requests. Eve…
> Every repo is owned by a team. Access is only ever per-team.
This is indeed the working pattern, and applies not just to GitHub and organizing teams there, it's a useful pattern to use everywhere. Don't think "Give access to this user" but rather "Give access to this team, which this user is current a part of" and it solves a lot of bothersome issues.
Re: Every GitHub object has two IDs
#64Earlier quoted context omitted.
> Sounds like you’ve maybe never actually run a service or API library at scale. What was the saying? When your scale is big enough, even your bugs have users.
Yeah, but when you are big enough you can afford to not care individual users. VScode once broke a very popular extension that used a private API. Microsoft (righteously) didn't bother to ask if the private API had users.
VScode is free, so not really money on the line. Easy decision. Things get complicated when money gets involved.
Re: Every GitHub object has two IDs
#65In database design typically it recommends giving out opaque natural keys, and keeping your monotonically increasing integer IDs secret and used internally.
That is a best practice for two real reasons: 1. You don't want third parties to know how many objects you have 2. You don't want folks to be able to iterate each object by incrementing the id But if you have composite IDs like this, that doesn't matter. All objects that belong to a repository have the repository id inside them. Incrementing the id gives you more objects from the same repo. Incrementing the repo id g…
What if you used some id that does not allow to count objs like guid?
Re: Every GitHub object has two IDs
#66The only GitHub identifier Ive ever bothered to store explicitly (I.e., in its own dedicated column) is an immutable URL key like issue/pr # or commit hash. I've stored comment ids but I've never thought about it. They just get sucked up with the rest of the JSON blob. Not everything has to be forced through some normalizing layer. You can maintain coarse rows at the grain of each issue/PR and keep everything else in…
> immutable URL key like issue/pr they are not immutable because repositories can change URLs (renamed or moved to a different org).
Issue #, commit hashes, etc. are still immutable in this scenario. When you rename or transfer a GitHub repository, all of these keys are preserved.
What I do is store 2 tuples:
Repository: (Id, Org, Repo)
Issue/PR: (Repository.Id, #)
Transferring or renaming a repository is an update to 1 row in this schema.
Re: Every GitHub object has two IDs
#67Remember this article when you get upset that your own customers have come to rely on behavior that you told them explicitly not to rely on. If it is possible to figure something out, your customers will eventually figure it out and rely on it.
Once a system has a sufficient number of users, it no longer matters what you "explicitly" promised in your documentation or contract. Hyrum’s Law: all observable behaviors of your system will eventually be depended on by someone. Even if you tell users not to rely on a specific side effect, once they discover it exists and find it useful, that behavior becomes an implicit part of your system's interface. As a result…
Obligatory XKCD for this
Re: Every GitHub object has two IDs
#68Seems brittle unless GitHub is guaranteeing that they will never change their ID algorithms.
Re: Every GitHub object has two IDs
#69I 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…
+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.
Re: Every GitHub object has two IDs
#70Earlier quoted context omitted.
Yeah, but when you are big enough you can afford to not care individual users. VScode once broke a very popular extension that used a private API. Microsoft (righteously) didn't bother to ask if the private API had users.
VScode is free, so not really money on the line. Easy decision. Things get complicated when money gets involved.
If you think that just because VSCode is free there's no money on the line, you're not thinking about things the way others do. As I said, reputation alone definitely has a cost and Microsoft has partnerships where VSCode is strategic. They probably just made a calculation that there's not enough users and/or the users using that private API were strategically misaligned with their direction.