Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

I mean, they totally could have built it that way. But they didn’t. I was answering why stars were removed.

From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars. The downside is the behavior seen when a repo goes private, but my bet is that repositories being made private is far less frequent than calls to get a list of starred repos.



I totally get that - it's not an insane design decision it's just different from what my default suggestion would be. And to be honest - your source of truth database, on a system of this scale, is likely going to be detached from your pool of active data (possibly with some data shadowing, caching - what have you).

The thing that throws me off is that they shot themselves with this footgun - whenever we (munk-a's employer) footgun ourselves we remove the footgun to prevent future footgunnery. They made the original design decision one way, and when they were burned by it they didn't re-examine it.


FWIW, if the blog post had centered around “GitHub, it’s strange to me that you made this mistake and didn’t reevaluate the root causes, and now I’ve made the mistake and it sucks”, I’d not be griping all over the comments here.

It’s the framing that GitHub has inflicted a deep, irreparable wound to the author that I can’t reconcile with the facts.


> From a data complexity standpoint, it sounds like they decided they didn’t want to have to make calls to the authorization layer when parsing a user’s stars.

You can also solve that by adding a flag column, or putting privated stars in a different table. That tiny bit of denormalization shouldn't be more expensive than the current process, or the other costs of privating/unprivating a repo.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: