Why would that make a difference?

The guest middleware is an alias of RedirectIfAuthenticated. It's applied on routes that an authenticated user shouldn't see, e.g. login and registration pages. Are your routes inside a guest middleware block?

Hmm.. when I make that change it won't update as some other packages (like mailgun) require "dev".

That's not right. If we're talking about the mailer package, it definitely has stable releases.

What may have happened: since your composer file allowed dev versions, while installing the mailer you may have added a version constraint that doesn't yet exist as a stable release.

If you're worried about unstable versions, setting the constraint on a single package doesn't make the problem go away. Your project and all its dependencies can still install unstable versions. Even if laravel/framework itself is stable, dependency installed by it are not.

I'd switch to stable and fix the conflicting version constraints one by one.

What is minimum-stability set to in your composer.json file?

It's not straightforward.

1. There's no native browser API for monitoring traffic or gettings statistics.
2. To trigger any kind of monitoring through JS, all of the JS code itself would have to be downloaded and executed. And at that point, the HTML is already loaded, as are many other assets.

For the initial page load, I don't think there's anything you can do on the client.

After that, you might be able to monitor same-origin requests by rolling out your own service worker. Intercept fetch requests, perform the fetch yourself and calculate the response bytes before passing it to the event caller.

What is the use case for this? Is it purely for analytics? You can't use it reliably to enforce any kind of quota. For one, ad blockers may block navigator signals altogether.

The syncing part should be easy if you get everything else working. Send the data with an appropriate retry strategy and use an idempotency key to avoid processing the same report multiple times on the backend.

Yes it would. Where would the session data be stored? And why are you even thinking about removing columns?

It's no problem if you don't see any problems.

If you start seeing database errors due to a high volume of traffic, you can switch to something like Redis.

As already mentioned, the sessions table already has a last_activity column (Unix timestamp) that's updated on every request.

I don't understand the objection. If you change something in the DB and need to convert data, it's better to run it chronologically in a migration rather than accumulate one-off Artisan commands. Relying on manual commands is bad if you have any kind of CI/CD pipeline or zero-downtime update process.

As for re-running migrations in dev and testing, what's the issue? You run schema changes and data changes together. Except with migrate:fresh there are usually no rows to modify.

Regarding seeding / data migrations, here's the opinion of one Laravel core developer: https://youtu.be/HNgDhZYg3VI?si=DVnuh4USmoL-pYEX&t=91

Schema changes are the main use case, but there's nothing wrong with migrating data too. It's the easiest way to keep the application state consistent. The feature is called database migration, not schema migration.

You're right to update the data in the migration. The issue is the use of Eloquent model classes. You should instead use a query builder with hard-coded table and column names, e.g.:

$results = DB::table('packages')	
	->join('sites', 'packages.site_id', '=', 'sites.id')
	->selectRaw('packages.id as package_id, sites.client_id as client_id')
	->get();

(...)

DB::table('packages')->where('id', $result->package_id)->update([
	'client_id' => $result->client_id
]);

I wrote that off the cuff, so it may contain errors.

You don't know what's going to happen with the schema years later. The model will always try to use columns and relations from the latest schema, which may not match the database structure at this migration step.

If something changes about the Package -> Site relation, for example, then this migration step will fail: the Package model will try to use columns or tables that don't exist (yet).

That sound completely normal to me. I've done it many times.

Error text?..

Are you sure Eloquent in migrations is good? Migrations are about raw database tables/columns, Eloquent is about models which are "next level" compared to DB calls. Sometimes they align, sometimes not. You cannot guarantee your migrations chain is consistent and always replayed with this approach.

I believe you need something like this: https://github.com/TimoKoerber/laravel-one-time-operations

It's like migrations for data, not structure.

Laravel already has last_activity timestamp column in sessions table by default; I believe it updates on every request. Is that what you need?

This is a bit off-topic, but I'd advise against using Eloquent in migrations. Migrations represent a change in the database schema at a specific point in time, while Eloquent models rely on the current schema. If and when the models go through changes, your earlier migrations may start failing during tests or deployments and you have to rewrite them.

It's best to use the DB query builder and reference the columns and relations that exist at that point.

Edit. Looks like @glukinho already pointed this out. I skipped the reply because I thought it was from Lary.

Writing to the DB on every single request will definitely crush your database once you start seeing real traffic.

That's a massive hyperbole, unless your definiton of "real traffic" is thousands of requests per second. And then you're hitting other bottle necks first.

If Laravel accesses the DB during each request, e.g. by pulling a user model, the additional cost of updating a single timestamp is minimal. Most of the overhead comes from establishing a database connection.

Do you actually need all of those props in the frontend? Passing tons of configuration to every page is suspicious and feels like a code smell to me.

If you really need all of them, you don't have to send them on every request. You could, for example, pass them during the initial page load and keep them in localStorage:

1. In the Inertia middleware, check if the request is from Inertia ($request->inertia()). If it's not, share the configuration and constants in a config prop.
2. On the frontend, check if config exists in the page props. If it does, store it in localStorage. If not, pull the previously fetched values from localStorage.

That's just one solution. But I'd first consider if I truly need all of it and if there's a better way of doing things. I've never needed anything like that.

I just checked the app I'm currently working on: it's a fairly big app with 650 routes, and it only uses 18 global inertia props.

I recommend moving translations to the frontend, or rather the translations that are used there. I don't use Vue, but in React I've used react-i18next, which is ok. It has some nice features that Laravel's translator doesn't have, like safely embedding HTML tags. There are probably similar packages for Vue.

As for constants and config, how much data are you sending with every request? You should only pass a prop globally with share() if it's needed on every page. Everything else should be passed from the controller when needed in Inertia::render().

Most likely, you're still sending way less data during navigation than is sent in a traditional app, where the entire HTML is populated on the server. So it's probably not an issue.

I don't get why that would be used since the database isn't involved in job creation at all. You create a job and push it to the queue, in Redis or whatever. No need for a DB query when you can just generate a UUID in code.

The database is pretty lousy as a queue driver. The last time we tried it, we got a lot of locking issues between multiple queue workers. I think someone on Laravel's GitHub even said that it's not meant for production. It's much better to do that with Redis or some other in-memory driver.

Edit. Found the comment, it was from Taylor.

That's because the job ID is generated in code, not by a database. The job needs a unique ID before it's pushed to a queue worker.

The issue isn't with Laravel, it's your database. MySQL uses the InnoDB storage engine, which at one point had a 1000 byte size limit for its keys by default. It looks like your database has some old configuration.

Laravel's MySQL config uses the utf8mb4 encoding by default, where each character takes 4 bytes. Even if you shortened all string columns to 191 characters, the composite key size would exceed its limit.*

You can fix the problem by updating your MySQL config. Add or update these values in my.ini, then restart the database service and run migrate:fresh:

innodb_default_row_format = dynamic
innodb_file_per_table = 1

These are the modern defaults that remove the limitation. You can read what they do from the database docs.

* Although I must say, Laravel's defaults are pretty bad. 255 characters for an indexed UUID column? Why?

It sounds like it should work. Here are some things you could check if you're out of ideas:

1. Do you have anything funky in your app/bootstrap.php file, such as a custom ->withCommands() call?
2. Are you still manually registering a Kernel class somewhere? Search for occurrences of Kernel::class under app/ and bootstrap/.
3. You can always try running composer dump-autoload and php artisan optimize:clear, in case the autoload file or some caches are stale.

Are you registering the commands? In older versions it was done in app/Console/Kernel.php.

I must encrypt session data and I don't know if there is a different driver I can use for sessions while keeping the session data encrypted (and not paying for an additional service like Redis). I would prefer not to use cookies to avoid the additional work of providing cookie notices.

Encryption isn't an issue. You can encrypt session data or not, it works the same for any session storage. Except for cookie sessions, since Laravel always encrypts cookies.

I don't recommend cookie sessions (meaning session data kept in cookie contents), but you don't need notices for cookies that are necessary for the site to function. Plus your site is already using cookies. That's how Laravel identifies the user, as do most web apps.

If you have a filesystem available, file-based sessions should work well.

Here are the skills I'd consider the minimum requirements for a full-stack junior position:

• Basic coding
• HTML
• CSS
• Basic understanding of databases
• Basic understanding of networking
• Basic understanding of security
• Some experience with a backend framework (Laravel, Django, Express, etc.)
• Some experience with a frontend framework (React, Vue, Svelte, etc.)

If you can't explain the request-response model or don't know the difference between an array, a map and a set, your GitHub is completely irrelevant.

Test databases persist once they've been created, so they can be reused between tests. You'd only need to seed them once, e.g. by importing a dump of the existing test database. Is that not an option?

If every process ran simultaneous transactions in the same database, you'd get a lot of lock contention.

Yes. Use the --parallel option with --processes:

php artisan test --parallel --processes=8

Each process creates its own test database.

Edit. You need the brianium/paratest package for parallel tests:

composer require brianium/paratest --dev

Yes, php8.4-fpm is installed and /var/run/php/php8.4-fpm.sock exists

So you have PHP-FPM running but the socket file path is wrong in your Nginx config. Like I wrote 3 days ago:

If the service is running but the socket file is in another location, e.g. /var/run/php/php8.4-fpm.sock, you need to fix the path in your Nginx config.

If you read the post, you could've already fixed the issue.

I'm not going to spell this out any further, I've wasted enough time here.

Do tell, what is it that I clearly don't know?

That php-fpm.sock disappearing means this is an issue related to php-fpm. That should be everything you need to start diagnosing what's wrong if you're familiar with Linux.

Answer these questions to start: do you have php8.4-fpm installed, or have you tried installing it?

So why did it disappear when my script has not changed a bit, why was it previously there

I'm not psychic; I don't know what your script does. What commands does it run? Does it use apt? Are you installing PHP from Ondrej's PPA or Ubuntu archives?

A date on its own is means nothing. Don't get fixated on it and find out what's actually wrong.

@vincent15000 Every developer has repositories on their local computer. That .git directory in your project is a Git repository.

GitHub, GitLab, etc. are hosting platforms.

I must encrypt session data and I don't know if there is a different driver I can use for sessions while keeping the session data encrypted (and not paying for an additional service like Redis). I would prefer not to use cookies to avoid the additional work of providing cookie notices.

Encryption isn't an issue. You can encrypt session data or not, it works the same for any session storage. Except for cookie sessions, since Laravel always encrypts cookies.

I don't recommend cookie sessions (meaning session data kept in cookie contents), but you don't need notices for cookies that are necessary for the site to function. Plus your site is already using cookies. That's how Laravel identifies the user, as do most web apps.

If you have a filesystem available, file-based sessions should work well.

The database takes 30 seconds to start from a shut-down state. To save on database costs, the database shuts down after it has not received a query for 1 hour.

It doesn't sound like there's a lot of traffic if the DB can be idle for an hour. How much money could you save doing this? I'd at least set minimum capacity to 1.

You could also get a VPS for $5 a month and run your DB there if you're comfortable with Linux and know how to configure TLS and firewalls. My impression is that you don't need horizontal scaling right now.

Can you describe your production setup?

In local development, your browser typically connects directly to the local Reverb server. In production, you're usually going through Nginx, which handles TLS and proxies traffic to the Reverb server, which only listens on local connections.

Is that the setup you have?

What does the WebSocket connection in your browser's network tab look like (Request URL, Status Code, response headers)?

What do the MakeBid and EndAuction events in Laravel look like, especially their broadcastOn methods?

Are you sure cache isn't what you are after? For session data to be displayed just load the page that uses that session data. I don't understand why it would take 30 seconds.

If other data needs storing for retrieval use another table specific for that. You should never have to "query" sessions as they are available anyway.

Read the first paragraph where they describe their setup. Are you familiar with the concept of serverless?

They're using a serverless database that apparently scales to zero and has to restart on demand. I'd never try to run an app like that if the database is needed for regular browsing. They could use a different session driver, but that doesn't help much if the database is used for anything else. A 30-second wait time is an automatic disqualifier, no matter how infrequent.

If you want to run performance benchmarks, Laravel has utilities for it:

https://laravel.com/docs/13.x/helpers#benchmarking

Cache::memo() stores retrieved values in memory so that the underlying cache store is only hit once per record per request. It'll only have an effect if you try to fetch the same record multiple times in a single request.

You might see a big difference in the benchmarks if you crank up the number of iterations, but that's probably misleading. There might be no real performance benefit in practice.

You keep telling me how things should be, sure, but I already know that

There's no need to get snappy. I'm explaining what you need since you clearly don't know it.

I'm telling you how things are right now, so the big question is have you actually tried to install Nginx vs Apache on 22.04 after my OP?

I've installed both countless times on Ubuntu and other distros. But this has nothing to do with the installation of either. It has to do with php-fpm, or how it's used.

Here's what you need to do:

• If php-fpm (or php8.4-fpm) isn't installed, you need to install it.
• If it is installed, you need to start it.
• If the service is running but the socket file is in another location, e.g. /var/run/php/php8.4-fpm.sock, you need to fix the path in your Nginx config.

The only useful pieces of information you've given so far are:

• /var/run/php-fpm.sock no longer exists and your app doesn't work because of that.
• There's no php-fpm service.

I can't tell you exactly what is wrong just based on that.

If you had this file before the reboot:

/var/run/php-fpm.sock

Then you definitely had php-fpm running earlier.

You need php-fpm to run a Laravel app – or any PHP app for that matter – through Nginx. There are alternatives, but php-fpm is by far the most popular choice.

As I mentioned, the service may have a different name, such as php8.4-fpm. You can look for it:

systemctl list-unit-files | grep php

If you updated PHP and accidentally uninstalled php-fpm, you need to reinstall it.

Start the php-fpm service:

sudo systemctl start php-fpm

Then enable it so it starts automatically on boot:

sudo systemctl enable php-fpm

This is assuming the service is named php-fpm in your system, which it probably is if the socket file was named php-fpm.sock before you rebooted. Often the service is versioned instead, e.g. php8.4-fpm.

Understanding source code management, collaboration workflows, and version control practices might.

That's not important for newcomers. They'll learn about it on their first job. What matters is if they know the fundamentals of programming in whatever domain they're applying to.

Nobody will hire a developer who's just looking to get to a "better" company.

I would suggest code an app first following MVC and laravel conventions which is usually all that is needed. Then do any evaluations on the app. You may be jumping ahead of yourself.

So if I decide to follow the aws well-architected best practices (...) I will be able to deploy my Laravel/Nextjs to the EC2 server through SSH or through Github Actions?

These questions make no sense. You can deploy apps through GitHub actions or over SSH. AWS guidelines, let alone KPIs, have nothing to do with it.

I don't think I've seen you (@june92 or @june23) ask a single programming-related question on this forum. But you keep bringing up terms and buzzwords in wrong contexts. Reading random articles without understanding the context isn't learning.

Have you ever finished a complete app with Laravel? You should start with that.

Is this your old account by any chance: @june23

As my client do not want to increase the payment cost for the pusher so he denies for this.

Reverb is free.

If you think it's a link to malware, which it probably is, please don't spread it further.

What do you expect people to do with it? Download and install it on their own computers to help you?

Should I continue my conversation with this person?

Oh come on.

If you want to install an app, install it from the official website.

Do you, though? In which path is it? The error clearly says it doesn't exist, or it's not readable due to improper permissions.

You're mixing yarn and npm, which seems weird to me. Use npm run dev instead of yarn dev.

The bundler is complaining about not finding resources/admin/sass/admin.scss. Does it exist?

Anyone trying to follow that method is going to have a really hard time. And that someone might be you two years from now.

Right now you're doing everything from control flow to low-level operations within the create() method. I'd refactor it so it only handles the top-level logic, and all heavy lifting is delegated to local methods. This makes the code more readable and also naturally comments it. Example:

if (array_key_exists('profile_image', $data['user'])) {
	$storageUsed = $this->uploadImage($data);
}

If you need to modify the $data array in a subtask, you can pass it as a reference:

protected function doSomething(array &$data): void {
	$data['user']['something'] = true;
}

I was asking why you added that option. It's not in the database config file by default. Did you read what it does from the Postgres docs?

You've set target_session_attrs to read-write for all connections, which means you cannot connect to the hosts you defined under read if they're read-only connections.

You also have a separate host array at the root level in addition to read and write hosts. I don't know Laravel interprets this, but it might mess things up. I recommend you read the docs before continuing.

What are you trying to achieve by including it to begin with?

Oh, you're right: thread.

@adamnet You keep making the same mistake and asking the same question. Either accept that you'll occasionally lose work, or start using version control. If you want to be a serious developer, learn version control.