Okay, let's take a look at Telescope. Telescope is an elegant debug assistant for Laravel. It can provide you with insight on things like requests, exceptions, database queries, and so much more. So I have an app here set up already, and I have a few things installed, like Jetstream for Auth, and I already have Telescope installed. So installation is pretty straightforward. As always, just composer require it, and run this install command, which will generate a config and a service provider, which we'll take a look at, and then migrate the database. Now if you want, you can install it just on your dev environment, but Telescope can also

a config and a service provider, which we'll take a look at, and then migrate the database. Now if you want, you can install it just on your dev environment, but Telescope can also be used as a lightweight monitoring system for your app in production, and we'll take a look at that in the next video. So in this case, I just installed it this way. So let's take a look at the config and the service provider that it installs. So let's go to config, Telescope. So a bunch of settings here, which I'm just going to leave default for this video. For example, the URL you can hit to see the dashboard, and a bunch of other settings, which have good descriptions if you want to change them.

For example, the URL you can hit to see the dashboard, and a bunch of other settings, which have good descriptions if you want to change them. So if we just go to /telescope, then you can see the Telescope dashboard here. Before we get into all of these features here, as you can see, this sidebar will show you everything that Telescope keeps track of. So your workflow would be to keep Telescope open in a tab or another window, and just make requests to your app as usual, and Telescope will show everything here. So let's take a look at the service provider it generated as well. So we can use night mode if you like that. I prefer that.

session, and the response, even the associated views here, and even the queries that were ran. So everything you need to know about your request. And for all these other features here, it usually just links back to the request where it happened. So we're going to go through all of these here, just to see how Telescope displays the information. So commands. So any commands you run on the command line will show up here. So let's do a simple one, php artisan inspire will show a quote.

So any commands you run on the command line will show up here. So let's do a simple one, php artisan inspire will show a quote. And now you see it to show up here. And you can drill down as always, not too many options here, but everything you need will show here. So pretty straightforward. Next is the schedule. And I believe I have something set up in my app. So let's take a look at it. It's the app/Http/Kernel.php.

So let's take a look at it. It's the app/Http/Kernel.php. And this is where you set up. Actually, sorry, it's app/Console/Kernel.php. And this is where you set up a schedule. And I have one for running the inspire command every minute. And I'm also storing the output. So if I run php artisan schedule:run, you can see that it ran that and now that should show up here in our schedule tab. And again, you can drill down and see the information about that schedule as well.

And I have a route that just runs a bunch of jobs. So let's take a look at that. So this route right here, it just dispatches this number of jobs, and this job doesn't do much. So let's go to that. It just logs some information here. So let's go ahead and run horizon. And then let's run that route, or hit that route. So it's /jobs, and it's run 10 jobs here. Okay, jobs processing, and we should see the jobs show up here.

So it's slash jobs, and it's run 10 jobs here. Okay, jobs processing, and we should see the jobs show up here. So again, very similar to how horizon does it. And as always, you can drill down and see more information about that specific job. Okay. Next is batches. So this is a new feature in Laravel 8, I believe. And this allows you to batch your jobs. And this tab will just show you those batch jobs. So again, I have another route for that in my demo app here, back to our routes file.

And this tab will just show you those batch jobs. So again, I have another route for that in my demo app here, back to our routes file. And it's called batch jobs. So let's try running that. So if you're not familiar with batch jobs, they allow you to group jobs together. So you can do things after a group completes. So this example is pretty much straight from the documentation. So let's go ahead and run this. So it's called batch jobs. Let's go here.

Actually, not as jobs. Oh, yeah. So link back to the actual job that happened. What's next? The cache. So I have a route for that as well. Let's check it out. So /cache here. So it's trying to get a key called user. And if it finds it, it just returns it.

So it's trying to get a key called user. And if it finds it, it just returns it. But if it doesn't, it puts the user with an ID of one in the cache for eight seconds. So this tab will show if it's a hit or a miss, and it will display here. So the first time we run this, it should be a miss because it doesn't exist in the cache. And then within eight seconds, it should be hits because it's in the cache. So let's try that. Let's go back here, let's run cache. So the first time is hit, I'm going to refresh a few times.

Let's go back here, let's run cache. So the first time it's hit, I'm going to refresh a few times. And there we go, we get the user. And now it should be past eight seconds. And there we go. It's cached again. So if we look here, so the first one was a miss. And then I refreshed it a few times. And those were hits because it was within eight seconds. And then we repeat here.

And those were hits because it was within eight seconds. And then we repeat here. So we can see information about our cache here. And as always, we can drill down and see more information here. And like I said earlier, you can go back to the request that happened. Okay, what's next? So this is related to the dump server that was introduced in Laravel 5.7, I believe. So again, I have a route for that. So it's called /dumps. And this just dumps the two users here and returns dump completed after it's done.

So it's called dump. And this just dumps the two User instances here and returns dump completed after it's done. So let me just go off this tab for now. And let's visit that route. And as you expect, you should see the two dumps in the browser here. Okay, so that's what you expect when you dump it. And I personally use this pretty often when I'm debugging code. And I expect it to show up in my view, but sometimes it interferes with the view. So in this case, if you have the dump tab opened, and you hit this route or any dumps, then it won't show it in here.

So in this case, if you have the dump tab opened, and you hit this route or any dumps, then it won't show it in here. So we'll only get this message when I refresh. But we will get the dumps in here. So again, it doesn't interfere with your views. So it's another way to debug if you like that. Okay, what's next events. And you can see some events that happened when jobs were pushed to the queue. But I have another route here that has a event called SomeEvent. So let's go ahead and run that.

But I have another route here that has a Event called SomeEvent. So let's go ahead and run that. What was the route name events? Okay, event fired. And as always, it should show here. And in this case, SomeEvent is a broadcast event. So it has this label here. So if you take a look at SomeEvent, you'll see that it implements BroadcastEvent, or should broadcast. And again, as always, you can drill down and see more information about that event.

should broadcast. And again, as always, you can drill down and see more information about that event. So in this case, here's the event. And there's also a listener associated with that event. And you can see here. Okay, let's take a look at exceptions. So all the exceptions that are thrown in your app will show here. So again, I have a route that has or throws an exception. So /exceptions, and it just throws a general exception. So let's go to that.

So slash exceptions, and it just throws a general exception. So let's go to that. Okay, and there it is. And you can drill down. And you can even mark it as resolved if you like. So if you fix that exception, then go ahead and mark it as resolved. Okay, let's take a look at gates. So this is gates and policies, which are similar. And I have a policy in my demo app here. And in this case, I have a Post model.

And I have a policy in my demo app here. And in this case, I have a Post model. And only the person who created the Post can edit the Post. And this is the middleware that does that. It's using a PostPolicy. So there is the update method there. And again, it's checking if the logged in User is the actual user that created the Post. So if you remember, I'm logged in as User one right now. So I should be able to visit posts/1/edit. So let's try that.

So I should be able to visit posts/1/edit. So let's try that. posts/1/edit. And that should work. Am I logged in? So it doesn't work. I am not logged in. So that's why it doesn't work. So that's expected behavior. But now we should see that it was denied here.

So that's expected behavior. But now we should see that it was denied here. And again, you can drill down and see. So if you go back and actually log in, this should work. So user1 is user at user.com. And it was posts/1/edit and view for editing post, which I didn't actually do. But now there is the allowed one. What's next? Logs.

What's next? Logs. So there should be stuff in here because I believe my job logged some stuff. But let's go ahead and just run the route that I have here that just logs a bunch of stuff. So let's do that /logs. And you can see all of your logs in a nicely formatted table. Here we go. And there are all the logs. Okay, let's take a look at mail here.

And there are all the logs. Okay, let's take a look at mail here. So this will display all of your mailables. So again, I have a route here that sends off a generic email. Where is it? /mail. And I believe I have my log or my mail driver set to just log. Where is it? mail mailers log. Okay.

Mail mailers log. Okay. So that should be in the logs as well. So let's try /mail in the browser here. Mail. Okay. So mail was sent. There it is. Check the logs. Yeah.

And if you want, you can even download the email file to open it up in your mail client. Okay. What's next? Models. So this should show the CRUD operations on your models. So I'm logged in now. And if I were to go to the dashboard and update a User, then it should show there. So let's go to profile and change my name, save. And there you see User 1 was updated. And again, we can see more information here.

And there you see User one was updated. And again, we can see more information here. So any CRUD operations here should work. So if I log out and register a new User, say Andre, then this should show up as well as a create action. Models. And there it is there. Okay. What's next? Notifications.

What's next? Notifications. So as always, I have a route here for notifications. And I have a Notification called invoicePaid. Let's take a look at that. And this doesn't do anything, just has the default mail message in here. So they should also send a mailable. So this should show in the mail tab as well. So let's check this out in the browser. Notifications.

So let's check this out in the browser. Notifications. Okay. So notification sent. There is that new notification. And you can drill down and see all the information and check mail if that was sent. And there it is. Queries. So this is for every single query that's run in your application. So as I expect, there's a lot in here, and you can see the duration, and you can see

So this is for every single query that's run in your application. So as I expect, there's a lot in here, and you can see the duration, and you can see more information about that query as well. So Telescope actually has a feature which allows you to define what a slow query is. So you can monitor any slow queries and take action on them. So if you go to the config, so config/telescope.php, you'll see something for slow queries here. Yeah, this one. So it's considering 100 milliseconds to be a slow query. So right now, all of our queries are running really fast. So nothing is a slow query here.

So right now, all of our queries are running really fast. So nothing is a slow query here. But if I were to make it one millisecond, as you can see, some of them are above one, and some of them are below one, then I believe it should highlight in red for the slow queries. Let's save that, and let's refresh this. So there you go. It only happens for the new queries that happen. And as you see, we have this red badge, which shows the slow queries. Okay, what's next? Redis.

Okay, what's next? Redis. So if you're making use of Redis, I have Redis installed. And I believe I have a route here as well. You can see some information here already. But back to our routes file, there is a route for Redis here. So let's run that. It's just setting some values. And let's see if this works. Redis.

And let's see if this works. Redis. And Redis items set, and you see them appear here. So if you're making use of Redis, you can use this to debug any keys and values that you set in your Redis store. And the last one is views. So this is pretty heavy as well, just like requests. Every Blade view that you make use of will show here, including Blade components. So you can see there's a lot here because Jetstream makes heavy use of Blade components, and all of them are showing here.

So you can see there's a lot here because Jetstream makes heavy use of Blade components, and all of them are showing here. So yeah, if you're making a new application and you need more insight on everything that's happening, then definitely make use of Telescope. So like I said earlier, you can also use Telescope as a lightweight monitoring system. And we'll take a look at that in the next video.