Before we get started, come along for a quick two minute overview of the MVC architecture. MVC stands for "Model, View, Controller" and is the bedrock for building Laravel applications.

I hope you're excited. It's time to dig in. Now, as for prerequisites, you'll need access to a good editor, a terminal, and of course PHP and MySQL. We'll also need to get a tool called Composer installed on your machine.

It's very cool that we can whip up a fresh Laravel application by using composer create-project; however, there's an even simpler option that allows you to type laravel new project and, bam, you're up and running. In this episode, let's install it globally on our machine.

Extra Credit: Install Laravel Valet to make any new Laravel project accessible via http://app-name.test.

Let's begin with the basics. If you load the home page for any new Laravel app in the browser, you'll see a basic "welcome" splash page. In this lesson, we'll figure out how a route "listens" for a URI and then loads a view (or HTML) in response.

Now that we understand how a particular URI ultimately loads a piece of HTML, let's now figure out how to include some generic CSS and JavaScript assets.

The simplest form of our blog will surely consist of a list of blog post excerpts, which then individually link to a different page that contains the full post. Let's begin working toward that goal.

Before we reach for a database, let's discuss how to store each blog post within its own HTML file. Then, in our routes file, we can use a route wildcard to determine which post needs to be fetched and passed to the view.

Sometimes, you'll wish to limit a route wildcard to only a certain sequence or pattern of characters. Luckily, Laravel makes this a cinch. In this episode, we'll add a constraint to our route to ensure that the blog post slug consists exclusively of any combination of letters, numbers, dashes, and underscores.

Reaching for file_get_contents() each time a blog post is viewed isn't ideal. Think about it: if ten thousand people view a blog post at the same time, that means you're calling file_get_contents() ten thousand times. That surely seems wasteful, particularly when blog posts rarely change. What if we instead cached the HTML for each post to improve performance? Learn how in this episode.

Let's now figure out to fetch and read all posts within the resources/posts directory. Once we have a suitable array, we can then loop over them and display each on the main blog overview page.

At the conclusion of the previous episode, we considered adding metadata to the top of each post file. As it turns out, this metadata format has a name: Yaml Front Matter. Let's see if we can find a Composer package to help us parse it. This will give us a nice opportunity to learn how easy and useful Composer is.

Blade is Laravel's templating engine for your views. You can think of it as a layer on top of PHP to make the syntax required for constructing these views as clean and terse as possible. Ultimately, these Blade templates will be compiled to vanilla PHP behind the scenes.

The next problem we need to solve relates to the fact that each of our views contains the full HTML structure - including any potential scripts and stylesheets. This means, should we need to add a new stylesheet, we must update every single view. This clearly won't do. Instead, we can reach for layout files to reduce duplication. In this episode, I'll demonstrate two different ways to create layouts.

Every application will require a certain amount of environment-specific configuration. Examples for this might be the name of the database you're connecting to, or which mail host and port your app uses, or even special keys and secret tokens that third party APIs provide you. You can store configuration like this within your .env file, which is located in your project root. In this episode, we'll discuss the essentials of environment files, and then move on to connecting to a MySQL database (using TablePlus).

Now that we've properly connected to MySQL, let's switch our attention over to those mysterious migration classes. Think of a migration as a blueprint for a database table.

Let's now move on to Eloquent, which is Laravel's Active Record implementation. Eloquent allows us to map a database table record to a corresponding Eloquent object. In this episode, you'll learn the initial API - which should seem quite familiar if you followed along with the previous chapter.

Now that you're a bit more familiar with migration classes and Eloquent models, let's apply this learning to our blog project. We'll remove the old file-based implementation from the previous chapter, and replace it with a brand new Post Eloquent model. We'll also prepare a migration to build up the posts table.

In this lesson, we'll briefly discuss how to go about updating database records using Eloquent. Then, we'll review an example of why escaping user-provided input is essential for the security of your application.

In this lesson, we'll discuss everything you need to know about mass assignment vulnerabilities. As you'll see, Laravel provides a couple ways to specify which attributes may or may not be mass assigned. However, there's a third option at the conclusion of this video that is equally valid.

Laravel's route model binding feature allows us to bind a route wildcard to an Eloquent model instance.

Our next job is to figure out how to assign a category to each post. To allow for this, we'll need to create a new Eloquent model and migration to represent a Category.

Now that we have the concept of a Category in our application, let's make a new route that fetches and loads all posts that are associated with the given category.

We introduced a subtle performance issue in the last episode that's known as the N+1 problem. Because Laravel lazy-loads relationships, this means you can potentially fall into a trap where an additional SQL query is executed for every item within a loop. Fifty items...fifty SQL queries. In this episode, I'll show you how to debug these queries - both manually, and with the excellent Clockwork extension - and then we'll solve the problem by eager loading any relationships we'll be referencing.

In this lesson, we'll associate a blog post with a particular author, or user. In the process of adding this, however, we'll yet again run into the issue of needing to manually repopulate our database. This might be a good time to take a few moments to review database seeding. As you'll see, a bit of work up front will save you so much time in the long run.

Now that you understand the basics of database seeders, let's integrate model factories in order to seamlessly generate any number of database records.

Now that we can associate a blog post with an author, the next obvious step is to create a new route that renders all blog posts written by a particular author.

I think we're ready to begin constructing the actual blog design for this series. As discussed in episode four, I've already written the base HTML and CSS. That means we only need to download it from GitHub, and begin migrating it to our Laravel application. As part of this, we'll prepare the layout file and extract a handful of Blade components.

Extra Credit: Consider watching the optional HTML and CSS Workflow prerequisite series, where we write the HTML and CSS that is referenced in this chapter.

We're making great progress. Let's continue the conversion in this episode, as we take a break from Laravel to play around with CSS grids.

With the home page in reasonably good shape, let's now move on to the "view blog post" page and get that up and running.

We next need to make that "Categories" dropdown on the home page function as expected. I hate to break it to you, but we'll need to reach for a bit of JavaScript to make this work. Don't worry: I'll make this as painless as possible by pulling in the excellent Alpine.js library. Let's get through this, and we'll jump back into some Laravel-specific topics!

We've now successfully built the basic functionality for a dropdown menu, but it's not yet reusable. To remedy this, let's extract an x-dropdown Blade component. This will come with the side effect of isolating all Alpine-specific code to that single component file.

In this new section, we'll implement the search functionality for our blog. I'm going to demonstrate this in two steps. First, in this video, we'll simply get it to work. The code won't be reusable or pretty, but it'll work! Then, in the following episode, we can refactor a bit.