Code Examples Improvements #2: View on GitHub

Announcements
1

All code examples now come with a “View on GitHub” button:

OG Image - View on GitHub - 5
OG Image - View on GitHub - 51200×630 552 KB

This was previously present only if the user had published their solution to GitHub. Now it’s available on all code examples.

2

How we built this

Our goal here was to address one of the common complaints with code examples: since code examples only highlight specific files, it’s impossible to view files that aren’t highlighted.

We initially thought of just adding all files to the code examples UI but realized that there’d be a ton of cases to handle to offer good UX:

  • The # of files in a repository can sometimes be pretty huge, especially if a user has copied in dependencies (common in languages like C/C++ where package management isn’t great).
  • As codebases get larger users will want to navigate code like they do on GitHub or in their IDE – with collapsible folder-style navigation, and with search, fuzzy navigation etc. Our UI approach is more like GitHub Gists, it only really works for smaller pieces of code.

These cases pretty much ruled out rolling our own UI. We decided to use GitHub for this instead since (a) GitHub has already solved these problems well and (b) it’s a UI that users are comfortable with.

Most of the engineering work here was around ensuring we stay within GitHub’s per-org repository limits. GitHub enforces a maximum of 100k repositories per organization. We’ve got thousands of users viewing code examples on a given day so we’d run into that limit pretty quickly if we created a repository for each code example.

We decided to use something like a LRU cache:

  • We set a maximum number of repositories we’ll create (well within GitHub’s 100k limit)
  • We keep a track of the last time a user clicked “view on github” on a code example
  • Every time we exceed our fixed number of repositories, we delete the one that was last accessed.
  • If a user clicks “view on github” on a code example with a deleted repository, we create a new repository on the fly.

Our primary worry here is cache misses – each miss could cause a wait for ~5-10 seconds while we create a repository and push new code to it. We’ll monitor these closely. There could be some opportunities to improve our cache hit rate by pre-empting user clicks, for example by creating a github repository when a user “expands” a code example and not only when then click on the “view on github” link.