Laravel is typically used to build monoliths. A monolith is a web application that has a single, self-contained codebase as opposed to multiple, single-responsibility codebases all working together such as in the case of micro services. Because everything is all in one place, the code can quickly turn into an unmanageable mess as more and more features are added. This is why it's important to adhere to a set of standards which are best represented in the official Laravel documentation itself.
Laravel's Architecture
At the core, Laravel apps have a Model-View-Controller (MVC) architecture:
These three types demonstrate the separation of concerns principle which is prominent throughout the rest of the framework. Following this pattern is a best practice and is one of the first things I look for when I review code.
How I Use Laravel
I typically use Laravel for what it was intended - monolithic web applications. When starting a new project I use Breeze, Inertia and Vue. Breeze provides user authentication, and Inertia and Vue allow me to create more dynamic pages.
When I first started using Laravel I used plain Blade templates as these were easy to understand. Now, as a more experienced developer, I recognize the benefits of using Inertia and Vue. It's best to set these up from the start of the project rather than adding them later and having to refactor.
Other features I make use of throughout the lifecycle of a project are models and migrations. Migrations allow me to create database tables using special methods rather than SQL. By doing this I have a history of all database schema changes ever made. Models are for creating, reading, updating and deleting records. I find that using the Eloquent ORM is a lot more natural and human-readable than raw SQL queries. I also use factories and seeders for populating the database of my dev environment.