Let's use the laravel.com source code as the basis for our learning in this series. This code is freely available to review on GitHub. Specifically, we'll focus on the documentation layer. We see all these markdown files for each page of documentation. How are they loaded, parsed, and presented on the page? And how is versioning handled? We'll decode all of it. To begin this journey, however, we must first get the laravel.com source code running locally.
Now that we have the application running locally, let's figure out how a documentation page is loaded. We already know that each section is stored as a Markdown file. So how exactly are the files loaded and presented to the user?
It seems that, at some point, the companion Markdown for a requested documentation page is loaded, compiled, and cached. In this episode, let's figure out exactly how that workflow is organized and processed.
We've figured out how the Markdown files are loaded, and parsed. The only remaining step is to get the content on the page. In this episode, we'll learn how the content is passed to the view, while accounting the situations when an invalid documentation page is requested.
Now that we fully understand how the documentation is loaded, parsed, and rendered on the screen, let's move on to a different piece of the codebase. Are there additional performance considerations that we might learn from? Well, as it turns out, the answer is yes. The Laravel.com website adopts full page caching to vastly improve load times. Why boot the entire framework for each request, when you can easily render a cached HTML response instead?
In this episode, we'll put what we've learned to the test. Can we create a project from scratch that renders versioned documentation pages, written in Markdown? Let's use TDD to drive our workflow, while implementing the techniques we've learned from this series. Along the way, we'll review a number of key decisions, including:
View the source code for this episode on GitHub.