Laravel Prerequisites

Before we dig into the nuts and bolts of Laravel, let's first zoom out and discuss what exactly happens when a request comes in.

Before we get started, you must first ensure that up-to-date versions of both PHP and MySQL are installed and available on your machine. In this episode, we'll review how to go about this. Once complete, we can then install Composer.

We will see how we can dockerize our Laravel application and make our development experience a breeze.

We will talk about a feature called Facades - how to use Facades, how not to use them, and more. We will explore all the things we need to know about Laravel's service container.

When I learn a new framework, the first thing I do is figure out how the framework's default splash page is loaded. Let's work through it together. Our first stop is routes/web.php.

It's neat that we can provide a closure to handle any route's logic, however, you might find that for more sizable projects, you'll almost always reach for a dedicated controller instead. Let's learn how in this lesson.

So far, we've been using a simple array as our data store. This isn't very realistic, so let's learn how to set up a database connection. In this episode, we'll discuss environment variables, configuration files, and the query builder.

n the previous episode, we used the query builder to fetch the relevant post from the database. However, there's a second option we should consider: Eloquent. Not only does an Eloquent class provide the same clean API for querying your database, but it's also the perfect place to store any appropriate business logic.

In a previous episode, we manually created a database table; however, this doesn't reflect the typical workflow you'll follow in your day-to-day coding. Instead, you'll more typically reach for migration classes. In this episode, we'll discuss what they are and why they're useful.

It can quickly become tedious to generate all the various files you need. "Let's make a model, and now a migration, and now a controller." Instead, we can generate everything we need in a single command. I'll show you how in this episode.

When possible, the code you write should reflect the manner in which you speak about the product in real life. For example, if you run a school and need a way for students to complete assignments, let's work those terms into the code. Perhaps you should have an Assignment model that includes a complete() method.

Using the techniques you've learned in the last several episodes, let's integrate a free site template into our Laravel project.

We will organize an HTML template using Blade syntax to use the template with Laravel efficiently.

In this episode, you'll learn how to detect and highlight the current page in your navigation bar. We can use the Request facade for this.

Laravel provides a useful tool called Mix - a wrapper around webpack - to assist with asset bundling and compilation. In this episode, I'll show you the basic workflow you'll follow when working on your frontend.

Let's next learn how to render dynamic data. The "about" page of the site template we're using contains a list of articles. Let's create a model for these, store some records in the database, and then render them dynamically on the page.

Let's finish up this exercise by creating a dedicated page for viewing a full article.

We will learn about REST API, it's principles. We will also see how easy it is to develop RESTful systems with Laravel.

There are seven restful controller actions that you should become familiar with. In this episode, we'll review their names and when you would reach for them.

Now that you're familiar with resourceful controllers, let's switch back to the routing layer and review a RESTful approach for constructing URIs and communicating intent.

Now that you understand resourceful controllers and HTTP verbs, let's build a form to persist a new article.

Browsers, at the time of this writing, only recognize GET and POST request types. No problem, though; we can get around this limitation by passing a hidden input along with our request that signals to Laravel which HTTP verb we actually want. Let's review the basic workflow in this episode.

Before we move on to cleaning up the controller, let's first take a moment to review form validation. At the moment, our controller doesn't care what the user types into each input. We assign each provided value to a property and attempt to throw it in the database. You should never do this. Remember: when dealing with user-provided data, assume that they're being malicious.

So far. we've been manually fetching a record from the database using a wildcard from the URI. However, Laravel can perform this query for us automatically, thanks to route model binding.

Your next technique is to reduce duplication. If you review our currentArticlesController, we reference request keys in multiple places. Now as it turns out, there's a useful way to reduce this repetition considerably.

Named routes allow you to translate a URI into a variable. This way, if a route changes at some point down the road, all of your links will automatically update, due to the fact that they're referencing the named version of the route rather than the hardcoded path.

Let's now switch back to Eloquent and begin discussing relationships. For example, if I have a $user instance, how might I fetch all projects that were created by that user? Or if I instead have a $project instance, how would I fetch the user who manages that project?

Let's put our learning from the previous episode to the test. If an article is associated with a user, then we need to add the necessary foreign key and relationship methods. As part of this, though, we'll also quickly review database factories and how useful they can be during the development and testing phase.

Next up, we have the slightly more confusing "many to many" relationship type. To illustrate this, we'll use the common example of articles and tags. As we'll quickly realize, a third table is necessary in order to associate one article with many tags, and one tag with many articles.

Now that we've learned how to construct many-to-many relationships, we can finally display all tags for each article on the page. Additionally, we can now filter all articles by tag.

We now understand how to fetch and display records from a linking table. Let's next learn how to perform inserts. We can leverage the attach() and detach() methods to insert one or many records at once. However, we should also perform the necessary validation to ensure that a malicious user doesn't sneak an invalid id.

Thanks to the first-party package, Laravel UI, you can easily scaffold a full registration system that includes sign ups, session handling, password resets, email confirmations, and more. And the best part is you can knock out this tedious and common requirement...in minutes.

In this episode, we'll discuss the basic password reset flow. If a user forgets their password, a series of actions need to take place: they request a reset; we prepare a unique token and associate it with their account; we fire off an email to the user that contains a link back to our site; once clicked, we validate the token in the link against what is stored in the database; we allow the user to set a new password. Luckily, Laravel can handle this entire workflow for us automatically.

Our first core concept is collection chaining. As you've surely learned by now, when fetching multiple records from a database, a Collection instance is returned. Not only does this object serve as a wrapper around your result set, but it also provides dozens upon dozens of useful manipulation methods that you'll reach for in every project you build.

Laravel provides Cross-Site Request Forgery (CSRF) protection out of the box, but you still may not know exactly what that means. In this lesson, I'll show you a few examples of how a CSRF attack is executed, as well as how Laravel protects your application against them.

Laravel's service container is one of the core pillars of the entire framework. Before we review the real implementation, let's first take a few moments to build a simple service container from scratch. This will give you an instant understanding of what happens under the hood when you bind and resolve keys.

Now that you understand the basics of a service container, let's switch over to Laravel's implementation. As you'll see, in addition to the basics, it can also, in some cases, automatically construct objects for you. This means you can "ask" for what you need, and Laravel will do its best - using PHP's reflection API - to read the dependency graph and construct what you need!

Now that you have a basic understanding of the service container, we can finally move on to Laravel facades, which provide a convenient static interface to all of the framework's underlying components. In this lesson, we'll review the basic structure, how to track down the underlying class, and when you might choose not to use them.

We've spent the last two episodes reviewing Laravel's service container and facades. All of that work is about to pay off, as we move on to service providers. A service provider is a location to register bindings into the container and to configure your application in general.

The easiest way to send an email in Laravel is with the Mail::raw() method. In this lesson, we'll learn how to submit a form, read a provided email address from the request, and then fire off an email to the person.

It's useful to view a log of any mail that is sent while in development mode, but let's switch over to using Mailtrap. This will allow us to simulate a real-life email inbox, which will be especially useful once we begin sending HTML email.

So far, we've only managed to send a basic plain-text email. Let's upgrade to a full HTML-driven email by leveraging Laravel's mailable classes.

We can alternatively write emails using Markdown! In this lesson, you'll learn how to send nicely formatted emails constructed by the framework. For the cases when you need to tweak the underlying HTML structure, we'll also publish the mailable assets and review how to create custom themes.

A notification may be dispatched through any number of "channels." Perhaps a particular notification should alert the user via email and through the website. Sure, no problem! Let's learn how in this episode.

Here's a fun exercise. For this next notification channel, we'll choose one that I've personally never used: SMS messaging. As you'll see, even with no prior experience, it's still laughably simple to conditionally fire off text messages to the users of your application.

Events offer a way for one part of your application to make an announcement that ripples through the entire system. In this episode, we'll not only review the essentials, but we'll also discuss the pros and cons to this particular approach to structuring an application.

For any typical web application, some actions should be limited to authorized users. Perhaps only the creator of a conversation may select which reply best answered their question. If this is the case, we'll need to write the necessary authorization logic. I'll show you how in this lesson!

There will almost certainly be users in your application who should receive special privileges and access. As examples, consider a forum moderator or site administrator. In these cases, we can declare before and after authorizations filters before the intended policy ability is tested

Here's an optional feature that you might consider. If you exclude the ability name when authorizing from your controllers, Laravel will do it's best to guess the appropriate policy method to call. It does so by creating a map for the typical restful controller actions and their associated policy methods.

If you'd prefer not to execute authorization from within your controller actions, you can instead handle it as a route-specific middleware. I'll show you how in this episode.

Let's take things up a notch. Beginning with a fresh Laravel installation, let's build a full role-based authorization system that allows us to dynamically grant and revoke various abilities on a per-user basis.

You've reached the final project for "Laravel From Scratch." Great job making it this far! To put your skills to the test, our final task is to build a Twitter clone, called "Tweety." We'll need to build the design, and add the necessary functionality to login, follow friends, view a timeline, and favorite posts that we like.

In this episode, we begin with the initial project setup

Before we can dive into writing the core logic, let's first set aside fifteen minutes or so to design the main timeline page, using Tailwind.

Now that we have a nice - but static - layout in place, we can begin making the different sections dynamic. We'll begin with the core of our application: tweets!

It wouldn't be much of a Twitter-clone if we didn't allow users to follow one another. Let's begin implementing that functionality now.

Now that we have the necessary functionality to follow other Tweety users, we can fully expand the timeline to include all relevant posts.

Let's move on and implement a profile page for each user. This page should show their avatar, a short bio, and then a timeline their tweets. This lesson will give us the chance to flex our Tailwind chops!

When building your own applications, you'll likely run into situations where you require nested layout files. Let's leverage Blade components to make the whole process a cinch.

Let's build a "Follow Me" form for the profile page. This should toggle the follow status for the given user. To implement this, we'll discuss a few different approaches that you might consider

Before we build a form to edit a user's profile, we must first ensure that the proper authorization is in place.

As part of creating a form to edit a user's profile, let's also finally add support for custom avatars. This will give us a chance to review Laravel's file storage functionality.

There's currently no way to browse all of the users. Let's add an "Explore" page to solve this.

Here's the deal, most applications require hundreds of hours worth of work. We, on the other hand, have about three. With that in mind, we'll begin wrapping up this final project over the next two episodes. Let's begin the final stretch with a general sweep through the code-base, as we search for things to tweak or fix.

While there's naturally so much more we could implement, we unfortunately need to wrap up. We'll finish with a full review of how to implement a like/dislike system for tweets.

We've sadly reached the end of this series; however, if you'd like to continue working on the final project, I've included a list of recommended next steps within the GitHub repository's readme file. Feel free to fork and improve this toy project as much as you wish.