3 ms·
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 o
by mvdtnz 6mo ago
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 6mo agoYes, 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)
- Neywiny 6mo agoThat does seem very long so it's good you're working on it
- nchmy 6mo agoI'm curious, what causes the rails header to be so slow? They have a pretty good fragment caching story, don't they?
- Banditoz 6mo agoHas the team considered going back all-in on Rails and SSR instead of this hybrid approach?
- altairprime 6mo agoHave they completed the do-or-die Azure migration? I thought it had another year or something left..
- joshmn 6mo agois `current_user` really costing that much?
- AlotOfReading 6mo agoHow 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.