General

An Introduction to Laravel Queues and Temporary URLs

Published Feb 4, 2025

Updated Feb 4, 2025

9 min read

Laravel is a mature, robust, and powerful web framework that makes developing PHP applications a breeze. In particular, I want to demonstrate how to create a website that can be used to convert videos online using queue jobs for processing and temporary URLs for downloading the converted files.

This article is aimed at those who aren’t very familiar with Laravel yet.

Prerequisites

There are many ways to set up Laravel, and which is the best method may depend on your operating system or preference. I have found Laravel Herd to be very easy to use if you’re using Windows or macOS. Herd is a Laravel development environment that has everything you need with minimal configuration required. Command-line tools are installed and added to your path, and background services are configured automatically.

If you’re developing on Linux then Herd is not an option. However, Laravel Sail works for all major operating systems and uses a Docker based environment instead. You can find a full list of supported installation methods in the Laravel documentation. To keep things simpl,e this article assumes the use of Herd, though this won’t make a difference when it comes to implementation.

You will also need a text editor or IDE that has good PHP support. PhpStorm is a great editor that works great with Laravel, but you can also use VSCode with the Phpactor language server, and I’ve found Phpactor to work quite well.

Project Setup

With a development environment setup, you can create a new Laravel project using composer, which is the most popular package manager for PHP. Herd installs composer for you. composer installs dependencies and lets you run scripts. Let’s create a Laravel project using it:

composer create-project laravel/laravel laravel-video-converter

Once that is done you can navigate into the project directory and start the server with artisan:

php artisan serve

Awesome! You can now navigate to http://localhost:8000/ and see the Laravel starter application’s welcome page. Artisan is the command-line interface for Laravel. It comes with other utilities as well such as a database migration tool, scripts for generating classes, and other useful things.

Uploading Videos Using Livewire

Livewire is a library that allows you to add dynamic functionality to your Laravel application without having to add a frontend framework. For this guide we’ll be using Livewire to upload files to our server and update the status of the video conversion without requiring any page reloads.

Livewire can be installed with composer like so.

composer require livewire/livewire

With it installed we need to make a Livewire component now. This component will act as the controller of our video upload page.

php artisan make:livewire video-uploader

With that done you should see two new files were created according to the output of the command, one being a PHP file and the other being a Blade file. Laravel has its own HTML template syntax for views that allow you to make your pages render dynamically.

For this demo we’ll make the video conversion page render at the root of the site. You can do this by going to routes/web.php and editing the root route definition to point to our new component.

<?php

use App\Livewire\VideoUploader;
use Illuminate\Support\Facades\Route;

Route::get('/', VideoUploader::class);

However, if we visit our website now it will return an error. This is due to the app template being missing, which is the view that encapsulates all page components and contains elements such as the document head, header, footer, etc.

Create a file at resources/views/components/layouts/app.blade.php and put the following contents inside. This will give you a basic layout that we can render our page component inside of.

<!DOCTYPE html>
<html lang="{{ str_replace('_', '-', app()->getLocale()) }}">
	<head>
    	<meta charset="utf-8">
    	<meta name="viewport" content="width=device-width, initial-scale=1">
    	<title>WebM Video Converter</title>

    	<style>
        	html {
            	font-family: sans-serif;
            	background-color: #eaeaea;
        	}

        	main {
            	max-width: 1000px;
            	margin: 100px auto 0 auto;
            	padding: 32px;
            	border-radius: 24px;
            	background-color: white;
        	}

        	h1 {
            	margin-top: 0;
        	}

        	a {
            	text-decoration: none;
        	}
    	</style>
	</head>
	<body>
    	<main>
        	{{ $slot }}

        	<footer>
            	Laravel v{{ Illuminate\Foundation\Application::VERSION }} (PHP v{{ PHP_VERSION }})
        	</footer>
    	</main>
	</body>
</html>

The {{ $slot }} string in the main tag is a Blade echo statement. That is where our Livewire component will be injected when loading it.

Now, let’s edit the Livewire component’s template so it has something meaningful in it that will allow us to verify that it renders correctly. Edit resources/views/livewire/video-uploader.blade.php and put in the following:

<div>
	<h1>Hello, Laravel!</h1>
</div>

With that done you can go to the root of the site and see this hello message rendered inside of a box. Seeing that means everything is working as it should. We may as well delete the welcome template since we’re not using it anymore. This file is located at resources/views/welcome.blade.php.

Now, let’s go ahead and add uploading functionality. For now we’ll just upload the file into storage and do nothing with it. Go ahead and edit app/Livewire/VideoUploader.php with the following:

<?php

namespace App\Livewire;

use Illuminate\Contracts\View\View;
use Livewire\Attributes\Validate;
use Livewire\Component;
use Livewire\Features\SupportFileUploads\TemporaryUploadedFile;
use Livewire\WithFileUploads;

class VideoUploader extends Component
{
	use WithFileUploads;

	/**
 	* @var TemporaryUploadedFile
 	*/
	#[Validate('mimetypes:video/avi,video/mpeg,video/quicktime')]
	public $video;

	public function save(): void
	{
    	$videoFilename = $this->video->store();
	}

	public function render(): View
	{
    	return view('livewire.video-uploader');
	}
}

This will only allow uploading files with video file MIME types. The $video class variable can be wired inside of the component’s blade template using a form.

Create a form in resources/views/livewire/video-uploader.blade.php like so:

<div>
	<h1>WebM Video Converter</h1>

	<form wire:submit="save">
    	<input type="file" wire:model="video">

    	@error('video') <span class="error">{{ $message }}</span> @enderror

    	<button type="submit">Convert Video</button>
	</form>
</div>

You will note a wire:submit attribute attached to the form. This will prevent the form submission from reloading the page and will result in Livewire calling the component’s save method using the video as a parameter. The $video property is wired with wire:model="video".

Now you can upload videos, and they will be stored into persistent storage in the storage/app/private directory. Awesome!

Increase the Filesize Limit

If you tried to upload a larger video you may have gotten an error. This is because the default upload size limit enforced by Livewire and PHP is very small. We can adjust these to accommodate our use-case.

Let’s start with adjusting the Livewire limit. To do that, we need to generate a configuration file for Livewire.

php artisan livewire:publish --config

All values in the generated file are the defaults we have been using already. Now edit config/livewire.php and make sure the temporary_file_upload looks like this:

...

'temporary_file_upload' => [
	'disk' => null,    	// Example: 'local', 's3'          	| Default: 'default'
	'rules' => null,   	// Example: ['file', 'mimes:png,jpg']  | Default: ['required', 'file', 'max:12288'] (12MB)
	'directory' => null,   // Example: 'tmp'                  	| Default: 'livewire-tmp'
	'middleware' => null,  // Example: 'throttle:5,1'         	| Default: 'throttle:60,1'
	'preview_mimes' => [   // Supported file types for temporary pre-signed file URLs...
    	'png', 'gif', 'bmp', 'svg', 'wav', 'mp4',
    	'mov', 'avi', 'wmv', 'mp3', 'm4a',
    	'jpg', 'jpeg', 'mpga', 'webp', 'wma',
	],
	'max_upload_time' => 5, // Max duration (in minutes) before an upload is invalidated...
	'cleanup' => true, // Should cleanup temporary uploads older than 24 hrs...
	'rules' => 'max:102400', // NEW: Override default so we can upload long videos.
],

...

The rules key allows us to change the maximum file size, which in this case is 100 megabytes.

This alone isn’t good enough though as the PHP runtime also has a limit of its own. We can configure this by editing the php.ini file. Since this article assumes the use of Herd, I will show how that is done with it.

Go to Herd > Settings > PHP > Max File Upload Size > and set it to 100. Once done you need to stop all Herd services in order for the changes to take effect. Also make sure to close any background PHP processes with task manager in-case any are lingering, as this happened with me. Once you’ve confirmed everything is shut off, turn on all the services again.

If you’re not using Herd, you can add the following keys to your php.ini file to get the same effect:

upload_max_filesize=100M
post_max_size=100M

Creating a Background Job

Now, let’s get to the more interesting part that is creating a background job to run on an asynchronous queue. First off, we need a library that will allow us to convert videos. We’ll be using php-ffmpeg. It should be noted that FFmpeg needs to be installed and accessible in the system path. There are instructions on their website that tell you how to install it for all major platforms. On macOS this is automatic if you install it with homebrew. On Windows you can use winget.

On macOS and Linux you can confirm that ffmpeg is in your path like so:

which ffmpeg

If a file path to ffmpeg is returned then it’s installed correctly. Now with FFmpeg installed you can install the PHP library adapter with composer like so:

composer require php-ffmpeg/php-ffmpeg

Now that we have everything we need to convert videos, let’s make a job class that will use it:

php artisan make:job ProcessVideo

Edit app/Jobs/ProcessVideo.php and add the following:

<?php

namespace App\Jobs;

use FFMpeg\FFMpeg;
use FFMpeg\Format\Video\WebM;
use Illuminate\Contracts\Queue\ShouldQueue;
use Illuminate\Foundation\Queue\Queueable;
use Illuminate\Support\Facades\File;

class ProcessVideo implements ShouldQueue
{
	use Queueable;

	private string $videoPath;

	private string $outputPath;

	public function __construct(string $videoPath, string $outputPath)
	{
    	$this->videoPath = $videoPath;
    	$this->outputPath = $outputPath;
	}

	public function handle(): void
	{
    	$tempOutputPath = "{$this->outputPath}.tmp";

    	// Convert the video to the WebM container format (SLOW).
    	$video = FFMpeg::create()->open($this->videoPath);
    	$video->save(new WebM, $tempOutputPath);
    	File::move($tempOutputPath, $this->outputPath);
	}
}

To create a job we need to make a class that implements the ShouldQueue interface and uses the Queueable trait. The handle method is called when the job is executed. Converting videos with php-ffmpeg is done by passing in an input video path and calling the save method on the returned object. In this case we’re going to convert videos to the WebM container format. Additional options can be specified here as well, but for this example we’ll keep things simple.

One important thing to note with this implementation is that the converted video is moved to a file path known by the livewire component. Later and to keep things simple we’re going to modify the component to check this file path until the file appears, and while for demo purposes this is fine, in an app deployed at a larger scale with multiple instances it is not. In that scenario it would be better to write to a cache like Redis instead with a URL to the file (if uploaded to something like S3) that can be checked instead.

Now let’s use this job! Edit app/Livewire/VideoUploader.php and let’s add some new properties and expand on our save method.

use App\Jobs\ProcessVideo;
use Illuminate\Contracts\View\View;
use Illuminate\Support\Facades\Storage;
use Livewire\Attributes\Validate;
use Livewire\Component;
use Livewire\Features\SupportFileUploads\TemporaryUploadedFile;
use Livewire\WithFileUploads;

class VideoUploader extends Component
{
	use WithFileUploads;

    	/**
     	* @var TemporaryUploadedFile
     	*/
    	#[Validate('mimetypes:video/avi,video/mpeg,video/quicktime')]
    	public $video;

    	public ?string $jobStatus = 'Inactive';

    	public ?string $outputVideoLink = null;

    	public ?string $outputPath = null;

    	public ?string $outputFilename = null;

    	public function save(): void
    	{
        	$this->jobStatus = 'In Progress';
        	$this->outputVideoLink = null;
        	$this->outputPath = null;
        	$this->outputFilename = null;

        	// Store the uploaded file and generate the input and output paths of
        	// the video to be converted for the job.
        	$videoFilename = $this->video->store();
        	$videoPath = Storage::disk('local')->path($videoFilename);
        	$videoPathInfo = pathinfo($videoPath);
        	$this->outputFilename = "{$videoPathInfo['filename']}.webm";
        	$this->outputPath = "{$videoPathInfo['dirname']}/{$this->outputFilename}";

        	// Add the long-running job onto the queue to be processed when possible.
        	ProcessVideo::dispatch($videoPath, $this->outputPath);
    	}

    	...
}

How this works is we tell the job where it can find the video and tell it where it should output the converted video when it’s done. We have to make the output filename be the same as the original with just the extension changed, so we use pathinfo to extract that for us.

The ProcessVideo::dispatch method is fire and forget. We aren’t given a handle of any kind to be able to check the status of a job out of the box. For this example we’ll be waiting for the video to appear at the output location.

To process jobs on the queue you need to start a queue worker as jobs are not processed in the same process as the server that we are currently running. You can start the queue with artisan:

php artisan queue:work

Now the queue is running and ready to process jobs! Technically you can upload videos for conversion right now and have them be processed by the job, but you won’t be able to download the file in the browser yet.

Generating a Temporary URL and Sending it with Livewire

To download the file we need to generate a temporary URL. Traditionally this feature has only been available for S3, but as of Laravel v11.24.0 this is also usable with the local filesystem, which is really useful for development.

Let’s add a place to render the download link and the status of the job. Edit resources/views/livewire/video-uploader.blade.php and add a new section under the form:

<div>
	<h1>WebM Video Converter</h1>

	<form wire:submit="save">
    	<input type="file" wire:model="video">

    	@error('video') <span class="error">{{ $message }}</span> @enderror

    	<button type="submit">Convert Video</button>
	</form>

	<div wire:poll>
    	<p>Job Status: {{ $jobStatus }}</p>
    	@if ($outputVideoLink != null)
        	<a href="{{ $outputVideoLink }}" download>Download Converted File</a>
    	@endif
	</div>
</div>

Note the wire:poll attribute. This will cause the Blade echo statements inside of the div to refresh occasionally and will re-render if any of them changed. By default, it will re-render every 2.5 seconds. Let’s edit app/Livewire/VideoUploader.php to check the status of the conversion, and generate a download URL.

use App\Jobs\ProcessVideo;
use Illuminate\Contracts\View\View;
use Illuminate\Support\Facades\Storage;
use Illuminate\Support\Facades\File;
use Livewire\Attributes\Validate;
use Livewire\Component;
use Livewire\Features\SupportFileUploads\TemporaryUploadedFile;
use Livewire\WithFileUploads;

class VideoUploader extends Component
{
	use WithFileUploads;

    	...

    	public function render(): View
    	{
        	if ($this->outputPath != null && File::exists($this->outputPath)) {
            	// Create a temporary URL that lasts for 10 minutes and allows the
            	// user to download the processed video file.
            	$this->outputVideoLink = Storage::temporaryUrl(
                	$this->outputFilename, now()->addMinutes(10)
            	);

            	$this->jobStatus = 'Done';
            	$this->outputPath = null;
            	$this->outputFilename = null;
        	}

        	return view('livewire.video-uploader', [
            	'jobStatus' => $this->jobStatus,
            	'outputVideoLink' => $this->outputVideoLink,
        	]);
    	}
}

Every time the page polls we check if the video has appeared at the output path. Once it’s there we generate the link, store it to state, and pass it to the view. Temporary URLs are customizable as well. You can change the expiration time to any duration you want, and if you’re using S3, you can also pass S3 request parameters using the optional 3rd argument.

Now you should be able to upload videos and download them with a link when they’re done processing!

Limitations

Although this setup works fine in a development environment with a small application, there are some changes you might need to make if you plan on scaling beyond that.

If your application is being served by multiple nodes then you will need to use a remote storage driver such as the S3 driver, which works with any S3 compatible file storage service. The same Laravel API calls are used regardless of the driver you use. You would only have to update the driver passed into the Storage facade methods from local to s3, or whichever driver you choose.

You also wouldn’t be able to rely on the same local filesystem being shared between your job workers and your app server either and would have to use a storage driver or database to pass files between them. This demo uses the database driver for simplicity’s sake, but it's also worth noting that by default, queues and jobs use the database driver, but SQS, Redis, and Beanstalkd can also be used. Consider using these other drives instead of depending on how much traffic you need to process.

Conclusion

In this article, we explored how to utilize queues and temporary URLs to implement a video conversion site. Laravel queues allow for efficient processing of long-running tasks like video conversion in a way that won’t bog down your backend servers that are processing web requests.

While this setup works fine for development, some changes would need to be made for scaling this such as using remote storage drivers for passing data between the web server and queue workers. By effectively leveraging Laravel’s features, developers can create robust and scalable applications with relative ease.

This Dot is a consultancy dedicated to guiding companies through their modernization and digital transformation journeys. Specializing in replatforming, modernizing, and launching new initiatives, we stand out by taking true ownership of your engineering projects.

We love helping teams with projects that have missed their deadlines or helping keep your strategic digital initiatives on course. Check out our case studies and our clients that trust us with their engineering.

About the author(s)

Jamie Kuppens
I’m a software engineer with an interest in web development and some more esoteric things like emulator development.
@Reshurum @Reshurum

How to Implement Soft Delete with Prisma using Partial Indexes

Most APIs and applications that allow you to manage content have some form of deletion functionality. Sometimes you may want to make something recoverable after it’s been deleted, or perform the actual deletion later, and soft deletion is a way to accomplish this. Entities in your database may also have unique identifiers such as slugs associated with them as well, and when you delete things you typically expect these identifiers to become available for use again. In the case of soft deletes though your deleted entities will still be in the database! If you’re using Postgres or SQLite you can get the best of both worlds by using partial unique indexes, which will in the case of soft deletes would only add slugs on undeleted records to the index; however if you’re connecting a partial index compatible database with Prisma then everything isn’t rainbows and sunshine when it comes to partial indexes. A Simple Soft Delete Implementation Before getting into the issue with partial unique indexes, let’s implement soft delete in Prisma using middleware. The following example is adapted from the Prisma documentation regarding soft deletes, though with some slight alterations for convenience. ` The notable change here is this version could be extended to work with multiple models fairly easily by modifying the MODELS_SUPPORTING_SOFT_DELETE constant, and we also handle the throwable variants of the find actions as well. The latter change requires we create a custom type named ExpandedPrismaAction with additional actions as the imported Prisma types don’t have these actions for some reason even though they are encountered in actual usage. Anything specified in the model's constant is assumed to have a field named deletedAt that is nullable. In this example specifically it’s a timestamp field since it’s nice to know when something has been deleted, but it could also be a boolean if you so choose. With that done, soft deletion is transparently implemented, at least insofar as select queries go. If you plan on blindly running update and delete queries as well, then you will need to add middleware for those actions as well. The Problem So as stated before we plan on using unique slugs with our model, in this case slugs for posts, and to free slugs for usage later we need to exclude them from the unique index without deleting the post records outright. Unfortunately, at the time of writing this article Prisma doesn’t allow you to define partial indexes in your schema when defining unique indexes using @@unique inside of your schema. Thankfully, there is a way to workaround this issue. The Solution To workaround this issue you can manage your unique indexes outside of the Prisma schema, though it does come with its own pitfalls that I will cover later. This can be done by creating partial indexes in a migration file instead of defining them in the schema file. It should be mentioned that if you do this then you should ensure a conflicting index is not defined in the schema, or else Prisma will try to overwrite the other index. First let’s create a basic schema with the following contents defining posts: ` In the above schema I’ve left a comment that mentions where a partial unique index definition would go if it was supported. The problem with keeping the definition solely in the migration is that it makes it difficult to discover, and also doesn’t explain the reason why it’s there. Now that we have a Post model with a deletedAt column, create an empty migration and do the following: ` Then the contents of the newly created migration file will be as follows: ` With that all initialized and the middleware setup, and router handler defined, everything should work! Check out the full example on GitHub as I don’t show the full implementation of the example API in this article. The route handlers don’t look any different than you would expect as the middleware handles all of the heavy lifting for us. It is worth noting that DELETE handlers do look different with soft-delete as we’re not intercepting delete calls to Prisma. This is how the implementation of the deletion looks for this example: ` Caveats So there are some caveats to implementing partial delete in this way. The first being that the schema doesn’t reflect the state of the database 1:1. Thankfully, Prisma doesn’t care about untracked indexes existing, but knowing the index exists requires looking in the migration files instead of the schema. This is worked around by leaving a comment, but it still isn’t great. Another downside is that upsert calls do not work with the Prisma client. Making upserts with Prisma requires a unique key, but since Prisma doesn’t track this unique key the typings needed to call upsert do not exist. This can be worked around by making raw queries without the query builder. Summary I hope this article has helped you ease the integration of soft deletes into your application. You can find a full example on → GitHub ← that includes all of the above code snippets, a buildable project, and instructions on how to get it all working....

Feb 2, 2024

4 mins

Prisma

D1 SQLite: Writing queries with the D1 Client API

Writing queries with the D1 Client API In the previous post we defined our database schema, got up and running with migrations, and loaded some seed data into our database. In this post we will be working with our new database and seed data. If you want to participate, make sure to follow the steps in the first post. We’ve been taking a minimal approach so far by using only wrangler and sql scripts for our workflow. The D1 Client API has a small surface area. Thanks to the power of SQL, we will have everything we need to construct all types of queries. Before we start writing our queries, let's touch on some important concepts. Prepared statements and parameter binding This is the first section of the docs and it highlights two different ways to write our SQL statements using the client API: prepared and static statements. Best practice is to use prepared statements because they are more performant and prevent SQL injection attacks. So we will write our queries using prepared statements. We need to use parameter binding to build our queries with prepared statements. This is pretty straightforward and there are two variations. By default we add ? ’s to our statement to represent a value to be filled in. The bind method will bind the parameters to each question mark by their index. The first ? is tied to the first parameter in bind, 2nd, etc. I would stick with this most of the time to avoid any confusion. ` I like this second method less as it feels like something I can imagine messing up very innocently. You can add a number directly after a question mark to indicate which number parameter it should be bound to. In this exampl, we reverse the previous binding. ` Reusing prepared statements If we take the first example above and not bind any values we have a statement that can be reused: ` Querying For the purposes of this post we will just build example queries by writing them out directly in our Worker fetch handler. If you are building an app I would recommend building functions or some other abstraction around your queries. select queries Let's write our first query against our data set to get our feet wet. Here’s the initial worker code and a query for all authors: ` We pass our SQL statement into prepare and use the all method to get all the rows. Notice that we are able to pass our types to a generic parameter in all. This allows us to get a fully typed response from our query. We can run our worker with npm run dev and access it at http://localhost:8787 by default. We’ll keep this simple workflow of writing queries and passing them as a json response for inspection in the browser. Opening the page we get our author results. joins Not using an ORM means we have full control over our own destiny. Like anything else though, this has tradeoffs. Let’s look at a query to fetch the list of posts that includes author and tags information. ` Let’s walk through each part of the query and highlight some pros and cons. ` * The query selects all columns from the posts table. * It also selects the name column from the authors table and renames it to author_name. * It aggregates the name column from the tags table into a JSON array. If there are no tags, it returns an empty JSON array. This aggregated result is renamed to tags. ` * The query starts by selecting data from the posts table. * It then joins the authors table to include author information for each post, matching posts to authors using the author_id column in posts and the id column in authors. * Next, it left joins the posts_tags table to include tag associations for each post, ensuring that all posts are included even if they have no tags. * Next, it left joins the tags table to include tag names, matching tags to posts using the tag_id column in posts_tags and the id column in tags. * Finally, group the results by the post id so that all rows with the same post id are combined in a single row SQL provides a lot of power to query our data in interesting ways. JOIN ’s will typically be more performant than performing additional queries.You could just as easily write a simpler version of this query that uses subqueries to fetch post tags and join all the data by hand with JavaScript. This is the nice thing about writing SQL, you’re free to fetch and handle your data how you please. Our results should look similar to this: ` This brings us to our next topic. Marshaling / coercing result data A couple of things we notice about the format of the result data our query provides: Rows are flat. We join the author directly onto the post and prefix its column names with author. ` Using an ORM we might get the data back as a child object: ` Another thing is that our tags data is a JSON string and not a JavaScript array. This means that we will need to parse it ourselves. ` This isn’t the end of the world but it is some more work on our end to coerce the result data into the format that we actually want. This problem is handled in most ORM’s and is their main selling point in my opinion. insert / update / delete Next, let’s write a function that will add a new post to our database. ` There’s a few queries involved in our create post function: * first we create the new post * next we run through the tags and either create or return an existing tag * finally, we add entries to our post_tags join table to associate our new post with the tags assigned We can test our new function by providing post content in query params on our index page and formatting them for our function. ` I gave it a run like this: http://localhost:8787authorId=1&tags=Food%2CReview&title=A+review+of+my+favorite+Italian+restaurant&content=I+got+the+sausage+orchette+and+it+was+amazing.+I+wish+that+instead+of+baby+broccoli+they+used+rapini.+Otherwise+it+was+a+perfect+dish+and+the+vibes+were+great And got a new post with the id 11. UPDATE and DELETE operations are pretty similar to what we’ve seen so far. Most complexity in your queries will be similar to what we’ve seen in the posts query where we want to JOIN or GROUP BY data in various ways. To update the post we can write a query that looks like this: ` COALESCE acts similarly to if we had written a ?? b in JavaScript. If the binded value that we provide is null it will fall back to the default. We can delete our new post with a simple DELETE query: ` Transactions / Batching One thing to note with D1 is that I don’t think the traditional style of SQLite transactions are supported. You can use the db.batch API to achieve similar functionality though. According to the docs: Batched statements are SQL transactions ↗. If a statement in the sequence fails, then an error is returned for that specific statement, and it aborts or rolls back the entire sequence. ` Summary In this post, we've taken a hands-on approach to exploring the D1 Client API, starting with defining our database schema and loading seed data. We then dove into writing queries, covering the basics of prepared statements and parameter binding, before moving on to more complex topics like joins and transactions. We saw how to construct and execute queries to fetch data from our database, including how to handle relationships between tables and marshal result data into a usable format. We also touched on inserting, updating, and deleting data, and how to use transactions to ensure data consistency. By working through these examples, we've gained a solid understanding of how to use the D1 Client API to interact with our database and build robust, data-driven applications....

Dec 23, 2024

6 mins

JavaScript

Let's innovate together!

We're ready to be your trusted technical partners in your digital innovation journey.

Whether it's modernization or custom software solutions, our team of experts can guide you through best practices and how to build scalable, performant software that lasts.

An Introduction to Laravel Queues and Temporary URLs

Prerequisites

Project Setup

Uploading Videos Using Livewire

Increase the Filesize Limit

Creating a Background Job

Generating a Temporary URL and Sending it with Livewire

Limitations

Conclusion

Jamie Kuppens

You might also like

How to Implement Soft Delete with Prisma using Partial Indexes

D1 SQLite: Writing queries with the D1 Client API

Let's innovate together!

You might also like

How to Implement Soft Delete with Prisma using Partial Indexes

D1 SQLite: Writing queries with the D1 Client API