Category: Uncategorized

The CalDigit TS4 dock can add a lot of connectivity to a Mac with its 18-ports, as well as being able to recharge a MacBook Pro with 98W of power delivery.

Laravel 9 is now released and includes many new features, including a minimum PHP v8.0 version, controller route groups, a refreshed default Ignition error page, Laravel Scout database engine, Symfony mailer integration, Flysystem 3.x, Improved Eloquent accessors/mutators, and many more features.

Before we jump into the new features, we’d like to point out that starting with Laravel 9, Laravel will release a new major version about every twelve months instead of the previous six-month schedule:

Laravel uses a variety of community-driven packages as well as nine Symfony components for a number of features within the framework. Symfony 6.0 is due for release in November. For that reason, we are choosing to delay the Laravel 9.0 release until 2022.

By delaying the release, we can upgrade our underlying Symfony components to Symfony 6.0 without being forced to wait until September 2022 to perform this upgrade. In addition, this better positions us for future releases as our yearly releases will always take place two months after Symfony’s releases.

From the releases support policy documentation, here’s what you can expect going forward with tentative dates of upcoming releases:

Laravel 9 is the next long-term support version (LTS) and will receive bug fixes until February 2024 and security fixes until February 2025. Here are some of the major features that we’ve covered in detail in our A look at what is coming to Laravel 9 post:

• PHP 8 is the minimum version in Laravel 9
• New Design for routes:list
• New test --coverage option displays coverage directly in the terminal
• Anonymous Stub Migrations are now the default
• New Query Builder Interface
• PHP 8 String Functions
• Moved mailer functionality from SwiftMailer to Symfony Mailer
• Flysystem 3.x
• Improved Eloquent Accessors/Mutators
• Implicit Route Bindings With Enums (PHP 8.1)
• Controller Route Groups
• Enum Eloquent Attribute Casting
• Forced Scoped Bindings
• Laravel Breeze API & Next.js
• Laravel Scout Database Engine
• Full-Text Indexes / Where Clauses
• Rendering Inline Blade Templates
• Soketi Echo Server
• Optional Bootstrap 5 Pagination Views
• Improved Ignition Exception Page
• New str() and to_route() helper functions

Find out more about Laravel 9.x

These are just a few of the new features in Laravel 9 and to see a complete list check out the Laravel 9 release notes as well as the upgrade guide. Also, don’t forget about Laravel Shift if you want an easy way of updating.

If you prefer video format, check out Laracasts: What’s New in Laravel 9 also has free videos about this release.

Finally, we’d like to thank everyone who contributes, submits PR’s, shares ideas, and uses the framework. Laravel is genuinely a global team effort.

AWS S3 provides a place for us to store files off of our servers. There are some big benefits to this:

1. Backup/redundancy – S3 and similar have built-in backups and redundancy
2. Scaling – Savings files off-server becomes necessary in modern hosting, such as serverless or containerized environments, as well as in traditional load-balanced environments
3. Disk usage – You won’t need as much disk space when storing files in the cloud
4. Features – S3 (and other clouds) have some great features, such as versioning support for files, lifecycle rules for deleting old files (or storing them in a cheaper way), deletion protection, and more

Using S3 now (even in single-server setups) can reduce headaches in the long run. Here’s what you should know!

Configuration

There’s two places to configure things for S3:

1. Within Laravel – usually via .env but potentially also within config/filesystem.php
2. Within your AWS account

Laravel Config

If you check your config/filesystem.php file, you’ll see that s3 is an option already. It’s setup to use environment variables from your .env file!

Unless you need to customize this, then you can likely leave it alone and just set values in the .env file:

1# Optionally Set the default filesystem driver to S3
2FILESYSTEM_DRIVER=sqs
3 
4# Add items needed for S3-based filesystem to work
5AWS_ACCESS_KEY_ID=xxxzzz
6AWS_SECRET_ACCESS_KEY=xxxyyy
7AWS_DEFAULT_REGION=us-east-2
8AWS_BUCKET=my-awesome-bucket
9AWS_USE_PATH_STYLE_ENDPOINT=false

The config/filesystem.php file contains options like the following:

 1return [
 2    'disks' => [
 3        // 'local' and 'public' ommitted...
 4 
 5        's3' => [
 6            'driver' => 's3',
 7            'key' => env('AWS_ACCESS_KEY_ID'),
 8            'secret' => env('AWS_SECRET_ACCESS_KEY'),
 9            'region' => env('AWS_DEFAULT_REGION'),
10            'bucket' => env('AWS_BUCKET'),
11            'url' => env('AWS_URL'),
12            'endpoint' => env('AWS_ENDPOINT'),
13            'use_path_style_endpoint' => env('AWS_USE_PATH_STYLE_ENDPOINT', false),
14        ],
15    ],
16];

There’s a few options there we didn’t use in the .env file. For example, the AWS_URL can be set, which is useful for using other file storage clouds that have an S3 compatible API such as CloudFlare’s R2 or Digital Ocean’s Spaces.

AWS Configuration

Within AWS, you need to do 2 things:

1. Create a bucket within the S3 service
2. Create an IAM User to get a Key/Secret Key, and then attach a Policy to that user that allows access to the S3 API.

Like anything in AWS, creating a bucket in S3 involves looking at a ton of configuration options and wondering if you need any of them. For most use cases, you don’t!

Head to the S3 console, create a bucket name (it has to be globally unique, not just unique to your AWS account), choose the region you operate in, and leave all the defaults (including the ones that labeled “Block Public Access settings for this bucket”).

Yes, some of these options are ones you may want to use, but you can choose them later.

After creating a bucket, we need permission to do things to it. Let’s pretend we created a bucket named “my-awesome-bucket“.

We can create an IAM User, select “programmatic access”, but don’t attach any policies or setup anything else. Make sure to record the secret access key, as they’ll only show it once.

I’ve created a video showing the process of creating a bucket and setting up IAM permissions here: https://www.youtube.com/watch?v=FLIp6BLtwjk

The Access Key and Secret Access Key should be put into your .env file.

Next, click into the IAM User and add an Inline Policy. Edit it using the JSON editor, and add the following (straight from the Flysystem docs):

 1{
 2    "Version": "2012-10-17",
 3    "Statement": [
 4        {
 5            "Sid": "Stmt1420044805001",
 6            "Effect": "Allow",
 7            "Action": [
 8                "s3:ListBuckets",
 9                "s3:GetObject",
10                "s3:GetObjectAcl",
11                "s3:PutObject",
12                "s3:PutObjectAcl",
13                "s3:ReplicateObject",
14                "s3:DeleteObject"
15            ],
16            "Resource": [
17                "arn:aws:s3:::my-awesome-bucket",
18                "arn:aws:s3:::my-awesome-bucket/*"
19            ]
20        }
21    ]
22}

This allows us to perform the needed S3 API actions on our new bucket.

Laravel Usage

Within Laravel, you can use the file storage like so:

1# If you set S3 as your default:
2$contents = Storage::get('path/to/file.ext');
3Storage::put('path/to/file.ext', 'some-content');
4 
5# If you do not have S3 as your default:
6$contents = Storage::disk('s3')->get('path/to/file.ext');
7Storage::disk('s3')->put('path/to/file.ext', 'some-content');

The path to the file (within S3) gets appended to the bucket name, so a file named path/to/file.ext will exist in s3://my-awesome-bucket/path/to/file.ext.

Directories technically do not exist within S3. Within S3, a file is called an “object” and the file path + name is the “object key”. So, within bucket my-awesome-bucket, we just created an object with key path/to/file.ext.

Be sure to check out the Storage area of the Laravel docs to find more useful ways to use Storage, including file streaming and temporary URL’s.

Pricing

S3 is fairly cheap – most of us will spend pennies to a few dollars a month. This is especially true if you delete files from S3 after you’re done with them, or setup Lifecycle rules to delete files after a set period of time.

The pricing is (mostly) driven by 3 dimensions. The prices vary by region and usage. Here’s an example based on usage for a real application in a given month for Chipper CI (my CI for Laravel application), which stores a lot of data in S3:

1. Storage: $0.023 per GB, ~992GB ~= $22.82
2. Number of API Calls: ~7 million requests ~= $12
3. Bandwidth usage: This is super imprecise. Data transfer for this was about $23, but this excludes EC2 based bandwidth charges.

Useful Bits about S3

1. If your AWS setup has servers in a private network, and uses NAT Gateways, be sure to create an S3 Endpoint (type of Gateway). This is done within the Endpoints section in the VPC service. This allows calls to/from S3 to bypass the NAT Gateway and thus get around extra bandwidth charges. It doesn’t cost extra to use this.
2. Considering enabling Versioning in your S3 bucket if you’re worried about files being overwritten or deleted
3. Consider enabling Intelligent Tiering in your S3 bucket to help save on storage costs of files you likely won’t interact with again after they are old
4. Be aware that deleting large buckets (lots of files) can cost money! This is due to the number of API calls you’d have to make to delete files.