New in Laravel
Playing
18. Pipelines Receive a finally() Method

Episodes

0%
Your progress
  • Total: 2h 34m
  • Played: 0m
  • Remaining: 2h 34m
Join or sign in to track your progress

Transcript

00:00
Laravel pipelines are a really useful kind of hidden feature of Laravel. If you've used them, you'll be pleased to know that there is now a finally method
00:09
which is added to the pipeline class, which means that we can do tidy up after something has happened, once something fails, whatever we need to do. Let's take a look at a demo of this, and I'm using pretty much the example directly from the pull request over on GitHub to demonstrate this, just because I couldn't think of a better idea. Okay, so let's take a look at what we're
00:32
doing with our application. So we've got this deployment model in the database. This has a couple of columns that I've filled in, deployed at and stopped at. Deployed at will only be run once all of the steps that we are piping the deployment through have finished, but what we want to do is do an additional clear up step at the end and also fill in stopped at, regardless
00:56
of whether it was successful or not. Now of course this is a really basic example, but you can apply it to everything you're doing. Okay, so when we work with the pipeline, we're passing this object, this model that's been created through this create server just here, which can potentially throw a new exception. We get the deployment through here that we're passing through the
01:17
pipeline, and we get a next closure as well, which we invoke passing the current state of the deployment through to. Now this will fail if we don't call next or if we throw an exception, so that is when finally would usually get called. Let's go and just take a look at the other action that we have here. This just does absolutely nothing, and let's go ahead and just run this
01:37
in the browser and see what this looks like by default. So you can see here that deployed at is reached because both of the steps were taken or the deployment went through both of the pipeline steps, and let's take a look at what happens if things fail. So for example over in create server, if we get rid of the comment here and actually do throw this exception, what's going to happen here?
02:00
Well let's go ahead and run this, and of course we get the exception out here, but we want to feel this stopped at regardless of whether it failed or not. So we'd want to do a kind of final tidy up of everything. Now how would we normally do this before this change? Well we would use a try block, we would emit catch, there's no point in using catch here unless we actually wanted to catch
02:22
the exception, but we can use finally. This is just base PHP stuff that we can use. Then what we could do for the deployment is we could go ahead and touch the stopped at timestamp, and maybe we could do some other tidying up here. That would mean that if we go over now and give that a refresh, that throws that exception, but with the try finally block this will have gone ahead and
02:47
filled in stopped at for for us. So you can do pretty much anything you want in here, but this potentially looks a little bit messy. There's nothing wrong with doing it like this, but when we're talking about Laravel we're talking about fluent code, and now we have the ability to use a finally closure with a fluent method. So we can use finally here, let's get rid of this,
03:11
and we'll just say before, and we'll go ahead and comment this out. Now let's take a look at after. So we can get rid of the try catch or try finally block, and we can create this so it's a little bit tidier. Now finally doesn't go onto the end of here because the result of then is actually a boolean, so you don't want to add it onto the end of then. You want to do it as a sort of in-between step.
03:39
Now for this what we would do is either create out a separate class that could handle an invoke here to do lots of tidying up if you wanted to split this out, or you could do a long or short closure. It doesn't really matter what you do. Either way we want access to that deployment, and we want to do exactly the same thing. So let's say deployment touch and stopped at, and that should have exactly
04:02
the same effect as we saw before. We get a failure within one of them pipelines and stopped at is filled. So a really basic change, but if you are using pipelines and you are doing some clear up based on any of the things that you're piping this through failing, then this is going to be a welcome change rather than having to wrap it in a try finally.

Episode summary

In this episode, we explore a neat new addition to Laravel's pipeline system: the finally() method. If you've been making use of pipelines (or even if you haven't checked them out yet), you'll see how this new method helps clean up your code and handle tidy-up steps more gracefully.

We walk through an example (borrowed straight from the official pull request!) where we're working with a deployment model that tracks when something is deployed and when it's stopped. Normally, you might need to do a bit of PHP gymnastics with try and finally blocks to make sure cleanup happens regardless of success or failure. For example, updating a stopped_at column even if something blows up in the middle of your pipeline steps.

But now, with the new finally() method on the pipeline, we can attach a closure that'll always run at the end—no matter what happens in the steps. The video shows both the old PHP approach and the new Laravel way, letting you compare how much cleaner and more "fluent" your code can be.

By the end, you'll see how simple it is to use the new finally() method: just pop your finalizing logic right on the pipeline and you're done. It's a small but very welcome change if you're building apps and need this kind of reliable cleanup!

Episode discussion

No comments, yet. Be the first!