[mvdtnz]

I can't speak for GitHub but I've worked on multiple nav headers for large SaaS products and they can be ridiculously heavy weight to render given they appear on every page. They tend to be a dumping ground for features, many of which require their own permissions checks, feature flag checks, etc. it's not unusual to have to perform hierarchical permissions checks. They also tend to contain contextual info about the current nav state and dynamic information about navigable states.

A lot of this can be cached but it's easy to see why moving from one repo to another will invalidate most or all permission checks and feature flag checks.

[Matt138]

Yes, pretty much this as well as some additional complexities due to the issue content being in React and the header in Rails - to the cost of approx 500-800ms p50 for a page load vs sub 100ms for a nav to an issue in the same repo (or without the header which is what we tried with this change here)

[nchmy]

I'm curious, what causes the rails header to be so slow? They have a pretty good fragment caching story, don't they?

[Banditoz]

Has the team considered going back all-in on Rails and SSR instead of this hybrid approach?

[altairprime]

Have they completed the do-or-die Azure migration? I thought it had another year or something left..

[Neywiny]

That does seem very long so it's good you're working on it

[joshmn]

is `current_user` really costing that much?

[AlotOfReading]

How many checks are we talking? A well-implemented monotonic system should be able to do tens of thousands of these checks (or more) in the time budget I associate with a heavy page, and start before the entirety of the permissions/feature data is available.