Codecourse
@codecourse.com
📤 145
📥 51
📝 486
We create the most practical screencasts for developers
Canceling a batch in Laravel is one line. Making sure your jobs actually respect that cancellation is the real work.
about 2 hours ago
0
0
0
This week: canceling a running batch, skipping jobs with middleware, and using the finally callback to tell the difference between cancellation and failure. Episode is up.
loading . . .
Manually Stopping the Batch
Want more? Explore the library at https://codecourse.comOfficial ...
https://youtu.be/6aHEJSviWt4
about 3 hours ago
0
0
0
How are you handling cleanup when a batch gets canceled mid-run? Curious whether people are leaning on the finally callback, model events, or something else entirely.
about 6 hours ago
0
0
0
SkipIfBatchCancelled middleware on each job is the cleaner path. One line per job, no conditional logic scattered through your business code.
1 day ago
0
0
0
You can check $this->batch()->cancelled() inside a job and return early. It works. But doing that in every job is the kind of repetition that middleware exists to eliminate.
1 day ago
0
0
0
Everyone's talking about background AI agents running autonomous tasks. The boring infrastructure problem: what happens when you need to stop one mid-run. Laravel's batch cancellation is a good place to start thinking about this.
2 days ago
1
1
0
Bus::findBatch($id) is how you get a handle on a running batch. Worth putting a helper method on your model so you're not scattering that lookup across your codebase.
2 days ago
0
1
0
If you're learning Laravel, here's a new episode in the Getting Started with Laravel course.
https://codecourse.com/courses/getting-started-with-laravel
What course topic do you want to see next?
loading . . .
Getting Started with Laravel
Get comfortable with Laravel by building up your skills step by step. You’ll start with...
https://codecourse.com/courses/getting-started-with-laravel
3 days ago
0
1
0
New Youtube Video! we're looking at something that comes up the moment you start building anything with job batches in Laravel — what happens when you need to stop mid-run. The episode drops Friday.
loading . . .
Enjoy the videos and music that you love, upload original content and share it all with friends, family and the world on YouTube.
https://youtu.be/6aHEJSviWt4
3 days ago
0
1
0
The pattern here is simple: interface defines the contract, job implements it, trait reads from it at dispatch, database stores it. Each layer does one thing.
3 days ago
0
1
0
At what point does a jobs table become a lightweight audit log? If you're storing state, title, description, and failure reasons — that's getting close. Where do you draw the line?
4 days ago
0
1
0
On failure, update the current task row with a description pulled from the exception. The infrastructure for this is already there once you have title and description in place — it's just one more column.
4 days ago
0
0
0
Job metadata isn't just for display. A failed_reason column on server_tasks lets you capture exception data at failure time and surface it later — without digging through logs.
5 days ago
0
0
0
Once your job titles are dynamic and stored at dispatch time, reloading the page is trivial. Iterate over server_tasks, output title — done. No front-end mapping, no hardcoded copy.
5 days ago
0
0
0
Set the server as protected in the constructor. You'll need it for the actual job logic anyway, so you're not adding the parameter purely for metadata — it's doing double duty.
6 days ago
0
0
0
This week was about attaching metadata to Laravel jobs so your UI doesn't need to hardcode anything. Title, description, dynamic values from the model — all stored at dispatch time. Full episode:
loading . . .
Storing Job Metadata
Want more? Explore the library at https://codecourse.comOfficial ...
https://youtu.be/9rrz4MhmXGY
6 days ago
0
0
0
This week: storing metadata on queued jobs, enforcing a title/description interface, and making job labels dynamic from the model. The full episode is on YouTube:
loading . . .
Enjoy the videos and music that you love, upload original content and share it all with friends, family and the world on YouTube.
https://youtu.be/9rrz4MhmXGY
7 days ago
0
0
0
Passing the server model into the job constructor gives you access to its data inside title() and description(). You can build strings like "Creating server #42" dynamically, rather than returning a static label.
7 days ago
0
0
0
When a job fails in your app, what does your UI actually show the user? An error code? A generic message? Something pulled from the exception? Interested in how people handle this.
8 days ago
0
0
0
In the CreateTaskTrait, pull title and description directly from the job instance before dispatching. Because the interface guarantees those methods exist, no null checks needed.
8 days ago
0
0
0
Hardcoding job labels in the UI is a maintenance problem. As soon as you rename a job class or change its behaviour, your UI copy is stale. Store the label where it belongs: on the job.
9 days ago
0
0
0
Interfaces in Laravel jobs aren't just structural. They let you make guarantees at the point of persistence — when you write to the database, you know the data is there.
9 days ago
0
0
0
A ServerJobInterface with title() and description() methods enforces a contract. Any job that implements it must provide both. No guessing whether the data exists when you go to store it.
10 days ago
0
0
0
New Episode today. www.codecourse.com
10 days ago
0
0
0
Do you store metadata alongside your queued jobs, or do you reconstruct job context from the payload at render time? Curious what people are actually doing in production.
10 days ago
0
0
0
Two new columns on the server_tasks table: title and description. Simple migration, but it unlocks dynamic job labelling across your entire queue pipeline.
11 days ago
0
0
0
Storing jobs in the database gives you more than state tracking. You can attach metadata — title, description — to each task and use it directly in your UI without hardcoding anything.
11 days ago
0
0
0
This week was about getting Dusk's database setup right — separate MySQL database, correct env file, migrations running cleanly. Easy to skip early on, annoying to fix later. Full episode if you missed it.
loading . . .
Testing Inertia with Dusk
Want more? Explore the library at https://codecourse.comOfficial ...
https://youtu.be/ZIjZWXZSq5U
13 days ago
0
0
0
What's the part of your test setup you'd most want to go back and fix? Infrastructure, naming, structure — most projects have something.
14 days ago
0
0
0
Spent the week on Dusk database isolation — why in-memory SQLite doesn't work, wiring up a separate MySQL database, and what RefreshDatabase actually does in a browser test context. This one holds up.
loading . . .
Enjoy the videos and music that you love, upload original content and share it all with friends, family and the world on YouTube.
https://youtu.be/ZIjZWXZSq5U
14 days ago
0
0
0
The reason you want MySQL for Dusk tests rather than SQLite: e2e tests are supposed to replicate what a real user would hit. Switching the database engine is changing the environment in a way that matters.
15 days ago
0
1
0
At what point did you start taking test isolation seriously? For a lot of people it's after losing local data during a test run rather than before.
15 days ago
0
0
0
RefreshDatabase in a Dusk context runs migrations before each test and rolls them back after. Your testing database stays clean without you having to think about it.
15 days ago
0
0
0
phpunit.xml's in-memory SQLite config is great for unit and feature tests. Fast, isolated, no cleanup needed. Just don't assume it carries over to Dusk — it can't.
16 days ago
0
0
0
The simplest Dusk database setup: duplicate your existing MySQL database name, append _testing. Point your .env.dusk.local at it. Done. Separate data, same engine, no surprises.
16 days ago
0
0
0
Dusk can't use an in-memory SQLite database. It's running in an actual browser — the app has to serve real HTTP, which means a real, physical database on disk or in MySQL.
17 days ago
0
0
0
Do you bother matching your test database engine to production, or do you just use whatever's convenient? Genuinely split on whether it matters for most projects.
17 days ago
0
0
0
End-to-end tests should mirror real usage as closely as possible. Running Dusk against SQLite when your app uses MySQL in production is a subtle mismatch that can let things slip through.
17 days ago
0
0
0
New episode on Codecourse this week: Blade and view data — part of Getting Started with Laravel. codecourse.com
18 days ago
0
0
0
This week we're looking at database setup for Laravel Dusk — the parts that catch people out before they've written a single meaningful test. Episode drops Friday.
18 days ago
0
0
0
This week was about what happens before a route is matched — building a request object from PHP globals, binding it to the container via a service provider, and understanding what PSR-7 actually standardises. Full episode here if you missed it.
loading . . .
Everything Starts With Requests
Want more? Explore the library at https://codecourse.comOfficial sitehttps://www.codecourse.comTwitterhttps://twitter.com/teamcodecourse
https://youtu.be/mb4esYv5gXg
20 days ago
0
1
0
Most Laravel developers have never written $_SERVER directly. Is that a good thing, or does it mean we're missing something foundational?
20 days ago
0
0
0
Do you register things in service providers out of habit, or do you actually think through whether something should be shared, deferred, or bound to an interface?
20 days ago
0
0
0
This week we've been looking at how a PHP framework handles requests from the ground up — PSR-7, service providers, container bindings, superglobals. The episode that started it is on YouTube if you want to follow along.
loading . . .
Everything Starts With Requests
Want more? Explore the library at https://codecourse.comOfficial sitehttps://www.codecourse.comTwitterhttps://twitter.com/teamcodecourse
https://youtu.be/mb4esYv5gXg
21 days ago
0
0
0
Service providers are a good place to register infrastructure-level bindings. Request, config, database — things the rest of the app depends on. Keeps bootstrap logic in one place per concern.
21 days ago
0
0
0
PSR-7 is an interface contract. The package doesn't matter as long as it implements the interface. Your router, your container, your controllers — they all just depend on the interface, not the implementation.
21 days ago
0
0
0
If you don't understand what's in the request before your controller sees it, debugging gets harder. Knowing that getParsedBody() is just $_POST with structure removes a layer of mystery.
22 days ago
0
0
0
When you use shared on a container binding, you're telling it: resolve this once, cache the result, return the same instance on every subsequent call. Useful for anything that reads from globals — no point rebuilding it.
22 days ago
0
0
0
The request lifecycle isn't magic. Request comes in, router matches it, controller handles it, response goes out. Every PHP framework is a variation of that loop.
22 days ago
0
0
0
Building framework internals from scratch changes how you read framework source code. Has that ever been true for you — building something low-level making higher-level code click?
23 days ago
0
1
0
Load more
feeds!
log in