标签：#larave

Building a Multi-Vendor Home Services Marketplace with Laravel: Architecture, Workflows and Key Decisions Building a home services marketplace looks straightforward until you start mapping the actual workflows. A customer searches for a service, chooses a provider, selects a time slot, enters an address, pays, and receives confirmation. Simple enough. But behind that booking are several systems working together: customers, providers, services, locations, schedules, bookings, payments, invoices, notifications, and administration. For Laravel developers, the real challenge isn't creating another CRUD application. It's designing these components so the marketplace remains maintainable as providers, locations, services, and bookings grow. This article explores some of the most important architecture and development decisions to consider when building a multi-vendor home services marketplace with Laravel. 1. Think of It as Three Connected Applications A useful starting point is to stop thinking about the marketplace as one application. In practice, you're creating experiences for three different types of users: Customers Service Providers Marketplace Administrators Each has different responsibilities and permissions. Customer Experience Customers typically need to: Register and manage their account Select their location Discover services Find available providers View service details Choose an appointment date and time Save service addresses Create bookings Make payments View booking history Access invoices The customer interface should remain simple even if the system behind it is complex. A typical booking flow may look like: Location → Service → Provider → Date & Time → Address → Payment → Confirmation Every unnecessary step increases friction. 2. The Provider Side Is a Different Product The provider dashboard deserves just as much attention as the customer interface. A service professional or company may need to manage: Business profile Services Pricing Service areas

The cryptocurrency and decentralized finance ecosystems generate an overwhelming amount of data every single day. For developers building financial dashboards, algorithmic trading tools, or market research platforms, accessing clean, standardized, and reliable data is absolutely critical. Token Terminal has established itself as a premier provider of fundamental financial data for the crypto space, offering institutional-grade metrics across various blockchains and decentralized applications 1 . However, integrating complex third-party APIs into enterprise PHP applications often requires writing significant amounts of boilerplate code to handle edge cases, rate limits, and unexpected response structures. To solve this problem and streamline the developer experience, the PHP community now has access to a dedicated solution: the tokenterminal-php SDK. This new open-source package provides a robust, fully-typed, and developer-friendly PHP 8.1+ client for the Token Terminal API v2 2 . Designed with modern PHP standards and framework integration in mind, it abstracts away the complexities of the underlying HTTP transport, allowing developers to focus entirely on building their applications rather than wrestling with API mechanics. The Challenge of Integrating Financial APIs When working with comprehensive financial data APIs like Token Terminal, developers frequently encounter several architectural challenges. First, there is the issue of rate limiting. Token Terminal enforces a strict limit of 1,000 requests per minute 3 . When building data pipelines that ingest historical metrics across hundreds of assets, hitting this limit is practically guaranteed. A naive implementation will simply crash or drop data, requiring manual intervention. Second, the cryptocurrency space moves rapidly. Projects frequently rebrand, merge, or migrate to new smart contracts. The Token Terminal API handles this gracefully by issuing HTTP 308 Permanent Redirects when a requested project ID ha

Most i18n tutorials stop at "put your strings in a JSON file". That covers labels. It does not cover the thing that actually breaks: URLs. I run a personality test site in five locales (French, English, Brazilian Portuguese, European Portuguese, Spanish). Same site, five language trees, roughly 96 articles each. The first version had the shape every project seems to grow by accident: $prefix = $locale === 'en' ? '/en' : '' ; That line, or a cousin of it, spread across controllers, views and helpers. Every one of them was correct when written and wrong the moment a third locale showed up. The bug it produces is the worst kind: nothing throws, the page renders, and the Spanish version quietly links to French URLs. The rule that fixed it One rule, enforced by a test: no locale literal anywhere outside the config file. Not in controllers, not in views, not in helpers. If code needs to know something about a locale, it asks the config. Adding a locale then becomes: content files, plus one entry in config/locales.php . Nothing structural. 'default' => 'fr' , 'available' => [ 'fr' , 'en' , 'pt-br' , 'pt-pt' , 'es' ], Three helpers cover essentially every call site: locale_prefix () // '' for the default locale, '/es' otherwise locale_url ( '/disc' ) // prefixed, canonical, ready to print locale_slug ( 'groupe' ) // the localized route segment The part nobody warns you about: slugs are data Labels translate. Slugs are a different problem, because a slug is simultaneously a URL, a cache key, an SEO asset and a foreign key into your own content. The decision that saved me: one locale is canonical, always. French, in my case. Every slug in every other language resolves back to a French slug before anything else happens. $slugs = app ( SlugService :: class ); $slugs -> toLocale ( 'quatre-tendances' , 'es' ); // 'cuatro-tendencias' $slugs -> resolveToCanonical ( 'cuatro-tendencias' ); // 'quatre-tendances' Without that pivot you get N-to-N translation tables and, eventually, two

Fire toast notifications in Laravel from PHP, Alpine and plain JavaScript with one notify call, plus positioning, auto-dismiss and grouping, and no CSS framework in your bundle Here is a problem I hit on every project. A Livewire action finishes and I need to tell the user it worked, but the toast library I grabbed assumes Tailwind, or ships its own huge runtime, or only works from JavaScript when half my triggers actually live in PHP. Wiretoast is my answer to that, and this post is the fast path to using it. The problem You want to fire a toast from PHP, from Alpine, and from plain JavaScript with the same call, and you do not want to drag a CSS framework into your bundle to get it. How to install Start with Composer, then wire up the assets. I bundle with Vite, so I import the package CSS and JS into my entry files. // resources/js/app.js import ' @wiretoast/js/wiretoast.js ' ; import ' @wiretoast/css/wiretoast.css ' ; That @wiretoast alias is optional, and you set it up by pointing Vite at the vendor resources folder so the imports stay short. // vite.config.js resolve : { alias : { ' @wiretoast ' : path . resolve ( __dirname , ' vendor/edulazaro/wiretoast/resources ' ), }, }, Then the component goes once into your layout, and on the Vite path it injects no tags of its own. <x-wiretoast /> How to use it The fastest possible win is a one-liner in a Livewire component right after something succeeds. The helper is a component macro named notify , registered for you when Livewire is present. $this -> notify ( 'Profile updated' , 'success' ); Under the hood that dispatches a notify browser event, which is exactly what Alpine fires too. So the same toast from a purely front-end button looks like this. <button @ click= "$dispatch('notify', { message: 'Copied', type: 'info' })" > Copy link </button> The five types you can pass are success , error , warning , info and neutral , and a message can be a plain string or an object with a title and a message when you want a he

TL;DR — composer require bouda/laravel-make-pattern → php artisan make:pattern Post → 9 consistent files in seconds. DDD-ready, rollback included, every stub is yours to override. The problem I kept running into Every new Laravel project starts the same way. You know the architecture you want: Repository, Service, Controller, some Form Requests, a Resource, a Policy, a test. You've written this stack dozens of times. And every time, you either: Copy-paste from a previous project — and immediately introduce inconsistency between how PostRepository is structured vs CategoryRepository . Write everything from scratch — which is slow and error-prone. Use make:model -a — which gives you the Model, Migration, Factory, Controller, but nothing about repositories, services, or policies wired together. None of these feel like the right answer when you want a clean, layered architecture. So I built laravel-make-pattern . What it does One command: php artisan make:pattern Post Generates 9 files : app/Models/Post.php app/Repositories/Contracts/PostRepositoryInterface.php app/Repositories/PostRepository.php app/Services/PostService.php app/Http/Controllers/PostController.php app/Http/Requests/PostStoreRequest.php app/Http/Requests/PostUpdateRequest.php app/Http/Resources/PostResource.php app/Policies/PostPolicy.php tests/Feature/PostTest.php All consistently named, all using the same conventions, all generated from stubs you own and can override . The generated code Here's what the repository looks like out of the box: <?php namespace App\Repositories ; use App\Models\Post ; use App\Repositories\Contracts\PostRepositoryInterface ; class PostRepository implements PostRepositoryInterface { public function all () { return Post :: all (); } public function find ( string $id ) { return Post :: findOrFail ( $id ); } public function create ( array $data ) { return Post :: create ( $data ); } public function update ( string $id , array $data ) { $model = $this -> find ( $id ); $model -> u

Claude Code writes PHP in Laravel quite well, but it starts every session as a generalist. It does not know your project has three hundred migrations that should be thirty, that a @foreach two files over is firing an N+1, or that your modals follow one specific pattern. You end up re-explaining the same context constantly. LaraClaude packages that context as slash commands. It is a Claude Code plugin with over thirty Laravel skills, each a /lc: command. Install it once and you have audits, scaffolders and cleanup tools that already know Laravel. Here are the ones I run most. How to install LaraClaude installs through Claude Code's plugin system. Add the marketplace once, then install, so you get updates later: /plugin marketplace add edulazaro/laraclaude /plugin install laraclaude@edulazaro Or grab it directly from GitHub: /plugin install github:edulazaro/laraclaude You need Claude Code and a Laravel project. That is it for most skills; a couple that hit a live database also want Docker. Audit before you change anything Most skills default to a read-only report and only touch files when you add fix , so start by looking. /lc:find-n-plus-one scans your Blade views, Livewire components and controllers for a relationship accessed inside a loop, traces it back to the query that built the collection, and tells you the exact with() to add. /lc:find-n-plus-one /lc:security-audit is the other one I run on any project I inherit. It looks for SQL injection, XSS, mass-assignment and secrets committed to the repo, and like most fixable skills it takes a preview flag before it changes anything. /lc:security-audit # report /lc:security-audit fix --dry-run # preview the fixes /lc:security-audit fix # apply, with confirmation Clean up what has piled up Every long-lived Laravel app accumulates migration cruft: a create followed by twenty add_column and change_column files. /lc:consolidate-migrations groups them by table, classifies each table as safe to merge or not, and folds the A

Sometimes you need tags on a model. The usual answer is a tags table, a pivot, a slug and a belongsToMany , and you write it again in the next project with slightly different columns. Laraterms replaces that with a config entry and a trait, and it comes with the parts you normally bolt on later: hierarchy, per-tenant isolation and translations. This is the simple path first, then the two features you reach for next. How to install One package, its config and two migrations. composer require edulazaro/laraterms php artisan vendor:publish --tag = laraterms-config php artisan vendor:publish --tag = laraterms-migrations php artisan migrate Step 1: define a taxonomy A taxonomy is a kind of label, declared in config/laraterms.php . Start with a flat tags taxonomy; the file already ships one you can keep. 'taxonomies' => [ 'tags' => [ 'hierarchical' => false , 'max_terms_per_model' => null , 'scope' => 'tenant' , ], ], Step 2: tag a model Add the HasTerms trait and the model can hold terms. Attaching is find-or-create: pass a label, and the term is created the first time and reused afterwards. use EduLazaro\Laraterms\Concerns\HasTerms ; class Post extends Model { use HasTerms ; } $post -> attachTerm ( 'Laravel' , 'tags' ); $post -> attachTerms ([ 'Laravel' , 'PHP' ], 'tags' ); $post -> syncTerms ([ 'Laravel' , 'Vue' ], 'tags' ); // replace the tag set $post -> termsIn ( 'tags' ); // read them back Filtering by tag is a query scope, so it composes with the rest of your query. Post :: whereHasTerm ( 'laravel' , 'tags' ) -> get (); Post :: whereHasAllTerms ([ 'laravel' , 'tutorial' ], 'tags' ) -> get (); Hierarchical categories Set hierarchical => true on a taxonomy and its terms form a tree. Read the whole tree in one query, and walk a term's ancestry. 'categories' => [ 'hierarchical' => true , 'max_terms_per_model' => 1 , 'scope' => 'tenant' , ], use EduLazaro\Laraterms\Support\TermTree ; $tree = TermTree :: for ( 'categories' ); // roots with children, one query $term -> b

Hello world, it's Wednesday, August 5, 2026, and here's what happened This Week in PHP Internals. 13 stories this week, so let's get into it. But first, This week's episode is brought to you by Tideways . When a request is slow in production, Tideways takes you from symptom to root cause in minutes, with profiling, tracing, and monitoring built specifically for PHP. It installs in 5 minutes, there's no credit card required, and it's hosted in Germany. Start your free trial at tideways.com . This week's top story: the mass deprecation vote for PHP 8.6 is in its final week. All 35 ballots close Monday , August 10, and Gina P. Banyard posted the 1-week reminder so nobody gets caught out. Most of the 35 are passing comfortably. The interesting ones are the holdouts. list() is now deadlocked at 21 to 21 — a flat tie, nowhere near the 2/3 it needs. Reserving let stands at 22 to 11, which is exactly two-thirds — a single vote in either column decides it. The dechunk filter sits at 17 to 15 — still well short. The gettext _() alias is failing at 9 to 20, and reserving in , out , and inout is failing at 7 to 20, with 12 abstentions. Everything else you'd recognize from the list — the object-parameter cleanups, the is_double() family, spl_classes() — is cruising toward the finish. The thread itself turned into a corrections desk this week. Calvin Buckley relayed a note from Nora, who isn't on the list, pointing out: "The text for the metaphone deprecation isn't fully right. It lists \"linguistics\" as a replacement package, but that one actually uses php-src's metaphone internally too." Weilin Du, who proposed that item, conceded the docs point while standing by the idea, writing: "My point in deprecating it is to stop using ancient metaphone algo as a whole." Voters seem unbothered — metaphone stands at 19 to 6, with 15 abstentions. Rowan Tommins raised a bigger flag on reserving is : it would collide with Hamcrest, the test assertion framework, whose PHP port has 500 millio

Wiremodal is a framework-agnostic modal package for Laravel, which allows to handle modals, so you don't have co configure them in all your projects. It ships a few Livewire-side helpers that make exactly this pleasant. This post is the Livewire integration end to end: opening and closing from PHP, delivering a payload on open, the one trap to avoid, and the optional form panel for when a modal happens to be a form. How to install Pull the package in and get the assets onto the page. composer require edulazaro/wiremodal php artisan vendor:publish --tag = wiremodal-assets The service provider auto-registers and there is no config file. Point your layout at the published files: <link rel="stylesheet" href="{{ asset('vendor/wiremodal/css/wiremodal.css') }}"> <script src="{{ asset('vendor/wiremodal/js/wiremodal.js') }}" defer></script> If you bundle with Vite, skip the publish and import straight from the vendor directory instead, so a package update flows through without re-publishing anything: /* resources/css/app.css */ @import "../../vendor/edulazaro/wiremodal/resources/css/wiremodal.css" ; // resources/js/app.js import ' ../../vendor/edulazaro/wiremodal/resources/js/wiremodal.js ' ; Opening and closing from Livewire Define the modal once with the <x-wiremodal> component, give it a name , and fill the body and footer slots. Here is a delete confirmation: <x-wiremodal name="confirm-delete" title="Delete record?" size="sm"> <x-slot:body> <p>This action cannot be undone.</p> </x-slot:body> <x-slot:footer> <button type="button" data-wm-dismiss>Cancel</button> <button type="button" wire:click="destroy">Delete</button> </x-slot:footer> </x-wiremodal> The Cancel button carries data-wm-dismiss , and any element with that attribute closes the modal it sits in, so you never write a cancel handler. To open and close from the component itself, use the macros the package registers on every Livewire component: public function confirmDelete (): void { $this -> openModal ( 'confirm

Most Laravel applications do not become difficult to maintain because somebody made one obviously terrible architectural decision. They get there through dozens of small decisions that looked completely reasonable at the time. A controller grows beyond a comfortable size, so part of its logic moves into an Eloquent model. Later, the application needs to send a notification after an order ships. Then inventory must be checked through an external API. Accounting requests an ERP integration, and marketing wants loyalty points awarded after dispatch. Each change adds only a few lines. Since the Order model is already available wherever the feature is being implemented, adding one more method feels natural: $order -> ship (); It is concise, expressive, and pleasantly object-oriented. Six months later, however, that innocent method may be updating several tables, calling two APIs, dispatching events, sending notifications, and deciding whether the entire operation is allowed. The model has quietly become the place where the application runs its business workflows. That is the real problem. It is not that the model is “fat.” It is that persistence, domain decisions, and application orchestration have been mixed together until nobody can change one without understanding all three. Business Logic in Eloquent Models Is Not Automatically Wrong The common advice to remove all business logic from Laravel models goes too far. Eloquent follows the Active Record pattern. Martin Fowler describes Active Record as an object that represents a database row, encapsulates database access, and adds domain logic related to that data. In other words, an object containing both state and behavior is not an architectural mistake by itself. A model should be allowed to answer questions about itself: class Order extends Model { protected function casts (): array { return [ 'paid_at' => 'datetime' , 'expires_at' => 'datetime' , ]; } public function isPaid (): bool { return $this -> paid_at !== nul

A hands-on guide to being your own Identity Provider — with Laravel 12 and Passport v13. You will build a Central Portal that acts as an OAuth 2.0 Authorization Server, then wire up child sites ( Site A , Site B , Site C ) so a user logs in once and gets access to all of them. No Google. No Auth0. No Keycloak. No "Sign in with…" anything. You own the users table, you issue the codes and tokens, you hold the signing keys. The only dependency is laravel/passport , which implements the OAuth 2.0 protocol machinery — every identity decision is yours to make, and this guide walks through each one. The scope is deliberately narrow: authentication only. How a user proves who they are at a central server, and how a child site learns that identity. Everything else (admin CRUD screens, audit logging, UI theming) is left out. Everything here is buildable on a fresh Laravel install. No prior context needed. Table of Contents What We Are Building OAuth 2.0 Foundations System Architecture Authentication Workflows Part A — Building the Central Portal Part B — Building a Child Site Registering a Child Site End-to-End Testing Gotchas & Security Notes Reference Tables Appendix A — Extending to Multiple User Types Appendix B — Mental Model in One Page 1. What We Are Building The Problem You operate several web applications. Each has its own users table, its own login form, its own password reset flow. When a staff member joins, someone creates four accounts. When they leave, someone must remember to disable four accounts. Passwords drift out of sync. There is no single place to answer "who has access to what?" The Solution One central server owns identity. Every child site delegates login to it. ┌─────────────────────────────┐ │ Central Portal │ │ ┌───────────────────────┐ │ │ │ admin.portal.test │ │ Management UI │ │ │ │ — create users │ └───────────────────────┘ │ — grant per-site access │ ┌───────────────────────┐ │ │ │ sso.portal.test │ │ OAuth 2.0 endpoints │ │ (authorization ser

Building Laravel NATS: A Modern, Production-Ready NATS Integration for Laravel When building distributed systems, one of the biggest challenges is enabling services to communicate reliably without creating tight coupling. Laravel has excellent support for queues, events, broadcasting, and jobs, but when it comes to NATS , the ecosystem has been relatively limited. That's exactly why I built Laravel NATS . Instead of being just another wrapper around an existing PHP client, Laravel NATS aims to provide a Laravel-first developer experience while exposing the full power of NATS for modern event-driven architectures. In this article I'll explain: Why I built Laravel NATS Why you should consider NATS How Laravel NATS works Features that make it production ready Code examples Real-world use cases What makes this package different from existing solutions What is NATS? NATS is a lightweight, high-performance messaging system designed for cloud-native applications. Unlike traditional queues, NATS focuses on: Extremely low latency High throughput Simple publish/subscribe messaging Request/Reply APIs JetStream persistence Horizontal scalability Instead of applications calling each other directly: Order Service │ ▼ Notification Service Applications publish events: Order Service │ ▼ NATS Server │ │ ▼ ▼ Email Analytics Every service becomes independent. Why Laravel Needed a Better NATS Package Most existing packages expose the underlying PHP client almost directly. That means developers still have to understand: client lifecycle connections serialization subscriptions queue consumers JetStream APIs Laravel developers expect something different. We are used to APIs like: Cache :: put (); Queue :: push (); Event :: dispatch (); The goal of Laravel NATS was to make NATS feel just as natural. Installing Laravel NATS Installation is straightforward. composer require zaeem2396/laravel-nats php artisan vendor:publish --tag = nats-config Then configure your environment: NATS_HOST=127.0.0

Ship a compliant cookie banner in Laravel and actually gate analytics and marketing scripts on the user's choice, using the wirecookies-saved event and a plain localStorage object as the consent gate. Wirecookies is a Laravel package which handles the cookies consent for you. It gives you a consent banner and a preferences modal from a single Blade tag, and, more usefully, it hands you a plain localStorage object and a browser event you can use as the gate for your analytics and marketing scripts. This article is built around that gate, not around how the banner looks. One thing to get out of the way first, because it will bite you otherwise: Wirecookies ships no JavaScript of its own and uses wiremodal's JS to open the preferences modal. If you skip the wiremodal import in the install steps, the banner still shows and Accept all / Reject all still work, but the Configure button and the floating re-open button silently do nothing, with no error in the console. Do the JS step. How to install Pull the package in with Composer. The service provider is auto-discovered, so there is nothing to register. composer require edulazaro/wirecookies Wirecookies depends on edulazaro/wiremodal , which Composer pulls in for you. Now import the stylesheet in resources/css/app.css , after a wire* base (wiremodal or wiretoast) that defines the theme tokens. /* resources/css/app.css */ @import '../../vendor/edulazaro/wiremodal/resources/css/wiremodal.css' ; @import '../../vendor/edulazaro/wirecookies/resources/css/wirecookies.css' ; Then bundle wiremodal's JS. This is the step that makes the Configure and re-open buttons work, so do not skip it. // resources/js/app.js import ' ../../vendor/edulazaro/wiremodal/resources/js/wiremodal.js ' ; How to use it Drop the single Blade component once, near the end of your layout. <x-wirecookies :policy-url="route('cookies')" /> First-time visitors get a bottom banner after a short delay. When they choose Accept all, Reject all, or save from the Con

Two months ago, I was given access to a codebase with an unfamiliar language and framework. I felt a...

Laravel is a popular PHP framework with routing, authentication, and database management built in. This guide deploys a Laravel app behind Nginx on Ubuntu 24.04, wires it to MySQL, secures it with Let's Encrypt, and builds a small dashboard that queries live data. Prerequisites: Ubuntu 24.04 with Nginx and MySQL installed, a non-root sudo user, a domain A record (e.g. app.example.com ). Create the Database $ sudo mysql mysql > CREATE DATABASE laravel_demo ; mysql > CREATE USER 'laravel_user' @ 'localhost' IDENTIFIED WITH mysql_native_password BY 'secure_password' ; mysql > GRANT ALL ON laravel_demo . * TO 'laravel_user' @ 'localhost' ; mysql > FLUSH PRIVILEGES ; mysql > EXIT ; Seed a demo table to query later: $ mysql -u laravel_user -p mysql > USE laravel_demo ; mysql > CREATE TABLE server_stats ( id INT AUTO_INCREMENT , server_name VARCHAR ( 255 ), region VARCHAR ( 255 ), cpu_usage DECIMAL ( 5 , 2 ), memory_usage DECIMAL ( 5 , 2 ), status ENUM ( 'active' , 'maintenance' , 'offline' ), last_updated TIMESTAMP DEFAULT CURRENT_TIMESTAMP , PRIMARY KEY ( id ) ); mysql > INSERT INTO server_stats ( server_name , region , cpu_usage , memory_usage , status ) VALUES ( 'app-01' , 'us-east' , 24 . 50 , 45 . 30 , 'active' ), ( 'db-01' , 'eu-west' , 12 . 75 , 78 . 20 , 'active' ), ( 'web-01' , 'ap-south' , 65 . 80 , 89 . 50 , 'active' ); mysql > EXIT ; Install Composer and PHP Extensions $ sudo apt update $ sudo apt install composer php php-curl php-fpm php-bcmath php-json php-mysql php-mbstring php-xml php-tokenizer php-zip -y $ composer --version $ php --version $ sudo systemctl restart php8.3-fpm php-fpm runs PHP as a service Nginx can talk to; php-mysql / php-mbstring / php-xml / php-tokenizer / php-zip cover Laravel's runtime requirements. Create the Laravel Project $ cd ~ $ composer create-project --prefer-dist laravel/laravel laravel-demo $ cd laravel-demo $ php artisan key:generate Edit .env : $ nano .env APP_NAME = laravel-demo APP_ENV = development APP_KEY = base64:APP

Laravel is one of my favorite frameworks because it allows you to move from idea to production incredibly fast. But after spending months building CelebrateMe a platform that helps people celebrate life's special moments through virtual gifts, wishlists, messages, and verified vendors—I realized something. I wasn't just using Laravel. I was relying heavily on the incredible ecosystem around it. Some packages solved problems that would have taken days (or weeks) to build myself. Others helped me monitor, debug, and secure the application as it grew. Here are the Laravel packages I now consider essential for almost every project. 1. Laravel Sanctum Use it for: API Authentication CelebrateMe has a Laravel API with a React frontend, so authentication needed to be secure without adding unnecessary complexity. Laravel Sanctum was the perfect choice. It provides: Personal access tokens SPA authentication Mobile API authentication Lightweight implementation For most APIs, Sanctum is more than enough. 2. Laravel Horizon Use it for: Queue Monitoring As CelebrateMe grew, background jobs became increasingly important. Things like: Sending emails Processing uploads Notifications Payment-related jobs Instead of wondering whether jobs were running correctly, Horizon gave me a beautiful dashboard to monitor everything in real time. If you're using queues and not using Horizon, you're missing out. 3. Laravel Telescope Use it for: Debugging Telescope quickly became one of my favorite development tools. Instead of scattering dd() statements throughout my code, I could inspect: Requests SQL queries Jobs Exceptions Cache operations Notifications It made debugging significantly easier. 4. Spatie Laravel Permission Use it for: Roles & Permissions CelebrateMe has multiple user types, each requiring different permissions. Managing authorization manually would have become difficult very quickly. Spatie's Permission package made it straightforward to assign roles and permissions while integra

Making classics more accessible I have a soft spot for mythology and classic stories. I have read most of the books on Abridged Shelf at least once, several of them more than that. But a lot of them are long . Epic poetry is not something you casually get through on a Tuesday evening, and the older translations can be genuinely hard going. The language demands focus, and focus is a resource I do not always have. So I made shorter versions. Abridged Shelf is a free library of public domain classics that I have abridged and modernized. Abridged, not summarized. The distinction matters a lot to me. I am not writing study notes or plot recaps. I take the actual text and condense it: the B-plots that do not carry the story, the scenes that spend forty lines describing a shield, those get compressed down into the beats that matter. What is left is still the story, told in its own voice, just tighter. The other half is the language. A lot of these translations are over a century old, and the English shows it. So I modernize spelling and phrasing into contemporary English. Again, not simplified. This is not a children's edition and I am not dumbing anything down. It is the same book, in language that does not fight you. I also made some editorial calls. For the Greek epics I use the Greek names rather than the Roman ones that a lot of older translations default to, because if we are reading Homer then it should be Athena and not Minerva. Small thing. Matters to me. And as a nod to a certain static site generator I maintain, the first book I abridged was the original Strange Case of Dr Jekyll and Mr Hyde . It is already short. Now it is very short. I did a few more by Stevenson after that, mostly because they were quick and I needed to get the workflow right before pointing it at an epic poem. The abridgment process I knew from the start that I needed to use AI for this. I also do not entirely trust AI, which is a useful combination of beliefs to hold at the same time. It me

Hi everyone,I just released my first package — strides/laravel-api-module.The idea was simple: stop copying the same boilerplate code every time you create a new API resource. So I made a generator that creates a clean module structure using the Action + Repository + Transformer pattern.What you get with one command:Action classes Repository with interface Transformer (using spatie/laravel-data) Model and migration Routes file The package is well documented with examples.Would love to hear your feedback and suggestions!Links:Documentation: https://strides-hovo.github.io/Laravel-api-module/ GitHub: https://github.com/strides-hovo/Laravel-api-module Packagist: https://packagist.org/packages/strides/laravel-api-module

Modern logistics is built on time-sensitive operations, yet traditional freight procurement suffers from friction. Legacy systems depend heavily on fragmented offline negotiations, opaque spot market prices, manual Lorry Receipt (LR) tracking, and coordination gaps between warehouse controllers and field drivers.To eliminate these operational bottlenecks, RoutePe Auto was engineered as a high-throughput Transport Management Software . The platform unites real-time spot bidding, pay-per-tender corporate procurement, vehicle discovery, automated freight billing, and live multi-point tracking into a unified ecosystem. Here is an architectural breakdown of how RoutePe Auto was designed using Laravel on the backend, React on the web frontend, a native Mobile App , and MySQL for transactional integrity. Architecture Overview ┌──────────────────────────┐ │ React Web Dashboard │ │ (Shippers / Logistics) │ └────────────┬─────────────┘ │ REST / WebSockets │ ┌──────────────────┐ ┌────────────▼─────────────┐ ┌──────────────────┐ │ Mobile App │◄────►│ Laravel API Gateway │◄────►│ MySQL Database │ │(Drivers/Fleet) │ │ & Execution Core │ │ (ACID Transactions) └──────────────────┘ └────────────┬─────────────┘ └──────────────────┘ │ ┌──────▼──────┐ │ Redis Queue │ └─────────────┘ The system operates across three tiers:The Web App Layer: Built with React, offering enterprise shippers a dynamic workspace to broadcast loads, review bids, manage tenders, and monitor active routes. The Field Execution Layer: A dedicated Mobile App for drivers and fleet operators, streaming real-time location updates, uploading electronic Proof of Delivery (ePOD) signatures, and receiving job dispatches. The Core Engine: A robust Laravel REST API backend handling business logic, asynchronous task dispatching, document generation, and balance ledger management against a relational MySQL store.Database Design in MySQLA core requirement for any Transport Management Software is strict transactional integrity.

The moment you add a code quality gate to CI, something quietly changes on your team. Developers stop arguing about code style in reviews because the robot handles it. Static-analysis errors stop reaching production because they can't pass the gate. You stop inheriting other people's technical debt because new errors are blocked immediately, even if old ones exist. That last point is the PHPStan baseline trick. We'll get to it. The Code Quality Job This job runs on every push and is intentionally fast — no database, no migrations, just PHP and a vendor folder: quality: name: Code Quality runs-on: ubuntu-latest steps: - uses: actions/checkout@v4 - name: Setup PHP 8.4 uses: shivammathur/setup-php@v2 with: php-version: '8.4' extensions: mbstring, pdo, bcmath, zip, intl coverage: none tools: composer:v2 - name: Cache Composer dependencies uses: actions/cache@v4 with: path: api/vendor key: php-8.4-composer-${{ hashFiles('api/composer.lock') }} restore-keys: php-8.4-composer- - name: Install dependencies run: composer install --no-interaction --prefer-dist --no-progress - name: Check formatting (Laravel Pint) run: ./vendor/bin/pint --test - name: Static analysis (PHPStan) run: ./vendor/bin/phpstan analyse --memory-limit=2G --no-progress pint --test runs in read-only mode — it checks without modifying files. Exit code 1 if any file has style drift. Run ./vendor/bin/pint locally (without --test ) to auto-fix before pushing. Configuring PHPStan Add a phpstan.neon to your API root: parameters: level: 8 paths: - app - Modules excludePaths: - vendor ignoreErrors: - identifier: missingType.iterableValue - identifier: missingType.generics Level 8 is strict. On a fresh project, aim for it from day one. On an existing codebase, start at level 4 and raise it gradually. The Memory Problem PHPStan at level 8 on a large codebase needs more than 512MB of RAM. Use --memory-limit=2G in CI. Locally, add a shortcut to composer.json : "scripts": { "analyse": "php -d memory_limit=2G vendor/bi