Job Batching Progress with Laravel
This episode is for members only

Sign up to access "Job Batching Progress with Laravel" right now.

Get started
Already a member? Sign in to continue
Playing
13. Storing job metadata

Episodes

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

Transcript

00:00
One of the benefits of storing the tasks in the database, along with the state, as we're doing, is that we can add any additional metadata to the server tasks, like a title and a description. We can use that data on the front end to show the job's title and description, and we can even make this dynamic. So for example, we could replace out a description with something that's very specific to that job using any of the data from our backend. So let's look at how we can add some additional metadata to each of these server tasks.
00:31
So when we get to the next section of the course, where we list them, we can just show this data and we don't need to hard code anything into the UI. Okay. So let's head back over and just think about a couple of things that we might want to add with a migration. So let's make out a migration here and we're going to add, we'll just call this metadata to the server tasks table.
00:54
Okay. Let's open that up. Add metadata to server tasks and let's fill in the title and description. So let's have a string in here for the title.
01:03
And why don't we just add some text or a string for the description just inside of here. Okay. Let's go ahead and run our migrations. Now that we've done that, we need to figure out where we're going to store this kind of data.
01:16
Now, probably the best place to store this will be in the job itself, but we want a common interface. So we know that any kind of server job always needs a title and a description to have it stored in the database. So we can create this out either inside of this server directory. So let's create out a directory here called interfaces.
01:36
And inside of here, let's create out a server job interface and we'll change the type here over to interface. Okay. So what do we want inside of here? Well, we want a title.
01:47
So let's create a method that we need to implement for a title. That's going to return to us a string. And let's do the same thing for a description here as well. That means that any server job that we create that implements this interface, this server job interface needs to have a title and description.
02:06
So we can add the method stubs either by our editor or manually. And that means that now we're going to go ahead and return a title and a description for each one. So let's just say create server and let's go and return creating your server. We'll just keep these really basic for now.
02:24
I'm going to run through just off camera and do these for each of these, and then we're ready to start to store them in the database. Okay. So I've just gone ahead and implemented the title and description for each of these jobs in here. Of course, making sure we implement the server job interface.
02:40
And now we need to figure out how to get these into the database. So remember what we did earlier over in our app server list, we always had this create task trait, depending on what kind of server or what kind of thing we're creating. This goes ahead and collects everything up. And of course it creates some data in the database because each of these tasks here are the actual job itself.
03:01
All we really need to do is extract this data out. So we can just say task and title here, and we can do the same thing for the description as well. So we can just put that directly into the database and because we have an interface on each of our server tasks, we know that these are always going to exist. Now that we've done this, let's go ahead and make sure we're not running our queue just because we don't want this to run through and just make sure this data gets stored.
03:26
And then I'm going to show you how to customize this data. If you need to show anything specific. Okay. So I'm going to head over to the database and just make sure everything is cleared out here without job batches.
03:37
Let's go over to the UI and click create server and let's head over to our server tasks. And there we go. So each of the title and descriptions have now been added for each of these that we need. Now, the good thing about this, rather than having a hard coded list on the UI of each of the jobs that you're running is you can now start to inject in any data that you need in this title and description.
04:00
Remember the reason that we're doing this is because it makes it more convenient when we refresh the page and iterate over a list of jobs to just get all this data in one go. Okay. So if we head back over to any of our jobs, let's go first of all, actually to app server, because we're not even passing the server in to each of these. So let's pass in the server for each of these jobs.
04:24
And we'll have that accessible now within the constructor of each of the jobs that we have. So let's finish that off and we'll open up create server here. We'll go ahead and set this as protected since we don't need it to be public. And we'll do the same for each of our jobs as well, actually.
04:39
So let's go ahead and just grab this and pass this into the constructor of every single one. And once we've done that, we now have access to our server inside of our job, which we'd need anyway, because you'll need to perform some sort of action on the model that you are creating. Okay. So now that that's in there, what we can do is, for example, if you wanted to output the server ID within the title, you could very easily do this, which is why we implemented this as a model.
05:07
So you could just access the server ID and you'll see it within the title. And then when we get to the UI part where we iterate over each of these, you can just dump out the title and it will contain everything that you need. Okay. Let's try this one more time.
05:20
So I'm going to go ahead and hit create server. Let's go to the database and check this one here, and this should now have a completely different title. So there we go. We're now storing all of the data metadata that we need about each of these tasks.
05:34
That means, like I said, when we go to iterate over these, it's going to be incredibly straightforward to just output the title with anything that's happening. Another thing that you can do is if some job fails at some point, you could update the current task. So if nginx installation failed, you could create another column in here with a description of why it failed. And from some sort of exception, you could take the data and output it as part of the error message.

Episode summary

In this episode, we're taking a closer look at how to store extra metadata about our background jobs (or tasks) in the database, which is super useful for building a dynamic frontend that can display things like job titles and descriptions without hardcoding them anywhere in the UI.

We'll start by adding a migration to our server_tasks table so it can store both a title and a description for each task. Then, we create a TypeScript interface to enforce that every server job must provide a title and description — this way, any job can have custom data attached to it, and it's always available when we need it.

Once that's set up, we'll show how to actually store this metadata when creating tasks, plugging the title and description right into our database whenever a job is created. We run through updating our job constructors so they receive the necessary data (like the server model) and show how you could start generating dynamic titles and descriptions (e.g. including the server ID in the job title).

By the end, you'll see how this makes the UI much more flexible and maintainable. Listing jobs in the frontend is now as simple as dumping out their metadata from the backend. Plus, we touch on how you could enhance this further, like recording failure reasons if a job errors out.

Basically, we're setting things up so every job is self-describing, and our UI can react to whatever's happening — no manual tweaks needed!

Episode discussion

No comments, yet. Be the first!