Forem: marius-ciclistu

The API Grand Prix: The Segregated Ledger and the Battle of the Tangled Engine

marius-ciclistu — Wed, 15 Apr 2026 19:16:20 +0000

Gemini generated image

This is Gemini’s fabulation about the segregated relations introduced in Maravel-Framework 10.65.0. Enjoy:

The Labyrinth was behind them, but the Emperor of Code had one final, grueling test for the API Grand Prix: The Cargo Loading Zones.

The track widened into a massive, high-speed supply depot. To finish the race, the chariots had to snatch heavy crates of supplies (Data Relations) while maintaining top speed. But there was a catastrophic flaw in the design of the traditional chariots.

In the Old Arenas, the chariot’s core engine gears ( Model Methods ) and the cargo chains ( Relations ) were all shoved into the same dark, chaotic hull. Whenever a driver called for a specific part, the chariot’s internal “Reflection Sorter” would stall the entire machine.

This blind, clunky system had to sift through thousands of tangled components, firing off heavy method_exists() checks just to distinguish a cargo chain from a steering bolt. Instead of a smooth ride, the engine spent its energy just trying to identify itself.

Gemini generated image

The Method Clash Catastrophe

The signal fire blazed, and the chariots hit the first Loading Zone. Instantly, the track was littered with wrecks.

The standard Laravel chariots were suffering from the dreaded Method Clash because everything shared the same space. A driver would call for a cargo chain named save, and that would accidentally grab the chariot’s core save() steering gear instead. The chariots violently violently swerved, crashing into the arena walls as their internal logic collapsed.

Even when they didn’t crash, the sheer weight of the “Reflection Rummage” was boiling their engines. They were wasting massive amounts of time just asking, “Is this a relation?” over and over again.

Pip and Tuck felt their own engine overheating. “We can’t keep rummaging like this!” Tuck yelled over the roar of the crowd. “We need a cleaner way to define our cargo!”

Suddenly, the Maravel Wizard appeared, riding alongside them on a glowing hover-disk. “Do not let your engine guess what your cargo is,” the Wizard boomed. “Define it. Segregate it.”

Gemini generated image

The Segregated Ledger and the ->r Lever

The Wizard handed Pip a glowing holographic map. It was the segregatedRelationsDefinitionMap().

“This map lives outside the tangled gears,” the Wizard explained. “It explicitly lists every single cargo chain using pure fn() closures. It even allows you to reuse chains or scope them without ever touching the core engine."

Pip installed the map onto the dashboard. But the Wizard wasn’t finished. He reached into his robes and pulled out a sleek, gleaming lever marked simply with ->r. He bolted it directly to the center console.

“When you need cargo,” the Wizard smiled, “do not seek into the dark. Pull the ->r lever. It bypasses the engine completely, reads the Segregated Map, and snaps the cargo directly to your hands."

Gemini generated image

The Grand Audit and the Victory Path

The next Loading Zone approached. Rival chariots ground their gears, their Reflection Arms smoking as they frantically searched for their relations.

Pip ignored his old engine box. He simply pulled the ->r lever. Snap. The exact cargo chain—relNameScoped—was fetched instantly. The Maravel chariot didn't lose a single fraction of a second. Because the isRelation check had been entirely bypassed, their execution speed spiked to levels the arena had never seen.

Pip didn’t even have to worry about the older cargo chains. As the chariot roared forward, the Segregated Ledger automatically identified the legacy methods, snapping them into the global map without a single reflection check. It was as if the engine already knew where everything was before Pip even asked. The transition was invisible; the speed was absolute.

Gemini generated image

They had eliminated the reflection bottleneck. By segregating their definitions, Pip and Tuck didn’t just win the Grand Prix — they rewrote the rules of the engine itself.

The API Grand Prix: The Labyrinth of the Legionnaires and the Victory of the 404 Firewall

marius-ciclistu — Wed, 15 Apr 2026 13:42:28 +0000

Gemini generated image

I continued to ask Gemini to fabulate, this time about the new Maravel’s Router introduced in version 10.67.0.

I have to admit my brain hurt until I managed to make it generate the images for this story to be in the same theme as the other chapters. As you can see Pip and Tuck had to change a white horse with a brown one during the event… :)) Anyway, here is the chapter 3 result:

The sun beat down on the sandy arena, hotter than ever before. For this leg of the API Grand Prix, the Emperor of Code had ordered a change of scenery. The wide-open track was gone, replaced by a mind-bending obstacle course: The Labyrinth of the Legionnaires.

This maze represented the ultimate challenge for a routing engine. Thousands of paths wound through towering stone aqueducts, some static and unchanging, others dynamic and twisting based on the identity of the chariot (/users/{id}). To make things worse, the Shadowy Wizard, still stinging from his previous defeat, had flooded the labyrinth with phantom roads and decoy gates, designed to trick chariots into endless loops (representing automated bot scanning and DDoS traffic).

At the starting line, rival chariots sat, their drivers looking nervous. They were still using the “Linear Scroll System.” Whenever they encountered a fork in the road, they had to stop, unroll a massive, dusty scroll (the route file), and check every single entry one by one until they found a match (Linear search/FastRoute). With the labyrinth constantly changing, their scrolls were becoming hopelessly outdated and heavy.

Gemini generated image

The Labyrinth Begins: The Battle of the Bots

The signal was given, and the chariots charged into the aqueducts. Chaos reigned instantly.

The Linear Scroll chariots immediately got bogged down. They hit the decoy gates set by the Shadowy Wizard. When they arrived at a dead end (/wp-admin or /phantom-data), their old engines tried to search the entire scroll to prove the path didn't exist. Their centurions (regex engine chunks) were working overtime, firing linear checks again and again, wasting precious horsepower just to confirm they were lost (Regex Tax). They traveled deep into the dead ends before realizing their mistake.

Pip and Tuck, however, engaged the Maravel Trie Navigation System. They didn’t search; they discovered.

As they approached high-traffic, unchanging aqueduct junctions, the chariot didn’t even slow down. The Hash Shield activated instantly. Before the main navigation engine even woke up, the shield instantly resolved the path with O(1) efficiency, shooting the chariot through the static gates without a single calculation.

Gemini generated image

The O(K) Precision: Walking the Trie

The further they went, the more complex the labyrinth became. Static paths disappeared, replaced by dynamic segments guarded by numeric guardians (/user/123).

Pip engaged Tier 2 of the Maravel engine: The Native Trie walk. The chariot didn’t consult a scroll anymore. Instead, it used native magic (strtok) to walk the prefix tree segment by segment.

Each time they hit a fork, the horses simply counted the segments (e.g., /user then /123). The complexity was decoupled from the size of the route file. Whether there were 10 dynamic routes or 1,000, a path with 3 segments always took exactly 3 precise magical checkmarks. It was surgical navigation.

The 404 Firewall: Defending the Chariot

Seeing them speed ahead, the Shadowy Wizard unleashed his phantom legion: hundreds of ghost chariots designed to clog the paths. They tried to draw Pip and Tuck into non-existent gates (/scanning-the-framework).

In traditional chariots, these ghost attacks were devastating because the engines would overheat checking every route entry to prove they were fake.

But the Maravel Trie acted as a fail-fast firewall. When a ghost path approached, the Trie walk failed at the very first segment. The chariot realized immediately that the path was a sham. It took only 1 or 2 quick array lookups before the Maravel chariot flatly rejected the route, conserving 100% of its energy while the ghost chariots evaporated. The Maravel horses were fresh and strong, while their competitors were breaking down.

Gemini generated image

The Golden Path to Victory

Pip and Tuck navigated the complex routes with flawless ease. They even hit a “Trailing Slash” junction. While other drivers argued with their centurions about whether /users/1 was different from /users/1/, the Maravel horses, using tokenized segments, treated both paths exactly the same natively, resolving to the same controller without a single line of extra confusion.

There was one last treacherous turn: the “Complex Queue,” where paths were twisted and greedy (/{any:.*}). These were truly unruly routes. But the Maravel Wizard had designed a Hybrid Fallback. These complex paths were automatically scoped during the Caching Phase into a small, isolated bucket.

When Pip encountered these, he calmly delegated only these few routes to the old Linear Scroll mechanics (FastRoute), allowing them to use their linear regex chunks one last time in a highly optimized, micro-scoped mode. Compatibility was 100% maintained, but the massive 404 Regex Tax was gone for good.

The Maravel chariot crossed the Labyrinth exit line first, setting a new arena record.

Gemini generated image

Pip and Tuck had proven that surgical precision, pre-compilation, and failing fast weren’t just about speed; they were about defending the kingdom of code itself. They navigated effortlessly ever after.

The API Grand Prix: The Sabotage of the Slog and the Victory of Structure

marius-ciclistu — Tue, 14 Apr 2026 18:22:04 +0000

Gemini generated image

Because Gemini likes to fabulate, I asked it to hallucinate the next chapter of The API Grand Prix. See also previous chapter.

Note: Laravel has no known vulnerability when using serialized objects in its queues if the APP_KEY is not leaked!

Once again, the great arena buzzed with the excitement of the API Grand Prix. Pip and Tuck were back, but this time, they were much faster, having accepted the wizard’s round, magical wheels on their heavy ‘Serialized Object’ wagon. They were moving smoothly, though their payloads were massive.

Gemini generated image

Suddenly, a massive boom echoed. From a hidden tunnel, a menacing, cloaked figure appeared. A shadowy wizard, twisted by legacy, vulnerable code, raised his hands. “If magic won’t stop them,” he sneered, “maybe this payload interception will!”

From a dark, boiling pit, he unleashed the POI (PHP Object Injection) — a wave of glowing, sticky, purple sludge that surged across the track. This corrupting goop was designed to seek out any serialized object graph and inject malicious properties, causing the objects to awaken with destructive intent and the wagons to lose control.

The Attack

The POI sludge targeted both vehicles.

The Serialized Slog Wagon: The sludge flew at the wagon. It easily attached to the complex, deeply nested O:16:"App\Jobs... stones making up Pip and Tuck's vehicle. The two were forced to dodge as the objects started to sizzle and crack under the attack. Worse, the sludge seeped into the wagon bed itself, hijacking the __wakeup and __destruct magic methods. One of the new round wheels violently locked up as an injected payload executed arbitrary code. “It’s hijacking our object chains!” Tuck yelled. “Our deserialization paths are breaking!” The wagon lurched and slowed, threatened with a total crash.

Gemini generated image

The Maravel Chariot: The sludge was also pelting the Maravel chariot. The Maravel driver, a smooth-operating engineer, remained completely calm. As the sludge hit the sleek chariot, it couldn’t get a purchase! The glowing round wheels repelled it instantly. Any sludge that hit the main frame simply slid off as if it were oiled silk. The chariot didn’t even slow down.

The Revelation of Maravel 10.70 Storable Arrays

As the shadowy wizard looked on in frustration, the wise old wizard (the Maravel-Rest-Wizard) appeared, observing the chariot. He didn’t need to cast a spell; he simply pointed to how the Maravel magic worked.

A magical, structured aura shimmered into existence around the entire Maravel chariot. This aura wasn’t a solid shield; it was composed of intricate, primitive, glowing geometric patterns. The wizard explained to the crowd (and a very confused Pip and Tuck):

“LOOK! Our magic is based on Maravel 10.70’s precise, structured logic! It does not rely on serialized objects that POI can corrupt upon unserializing. It uses pure, secure Storable Array Callables!”

The wizard waved his staff, and a magical text overlay appeared on the aura, showing the structured code:

[UserJob::class, 'sendEmail', ['id' => $user->id]]

“Because our payloads are pre-defined, non-injectable primitive arrays, the sludge has no object graph to corrupt! It’s clean, secure code by design.” The wizard’s lesson was simple: Primitive structures are non-injectable.

The Victory of Pure Structure

The shadowy wizard watched in horror as his ultimate sabotage was completely defeated by strict queueing practices. The Maravel chariot, completely unaffected by the sludge, crossed the finish line first. The driver was presented with a new, even bigger golden trophy, engraved with ‘API 10.70’ and a symbol of a perfectly structured, impenetrable array.

The serialized-object wagon, completely bogged down in the purple sludge and half-hijacked, didn’t finish. The crowd, however, cheered for both: they celebrated the victory of secure code and the realization that sometimes the best defense isn’t a thicker shield of encryption, but a fundamentally cleaner design.

Gemini generated mage

And so, the Maravel racers learned that accepting the magic of modern, array-callable code didn’t just make the journey lighter and faster; it protected them from the shadowy PHP saboteurs of the past. They built beautiful, and secure, things happily ever after.

Maravel-Framework 10.70: Eradicating PHP Object Injection from Background Queue

marius-ciclistu — Tue, 14 Apr 2026 07:24:16 +0000

Maravel-Framework

Maravel-Framework 10.70 brings Storable Array Callables to queues (and queued events) available both in the Maravel micro-framework and Maravelith.

This is a safer alternative to serializing objects when dispatching a message to the queue because PHP Object Injection is totally avoided on unserializing the payload. PHP Object Injection allows attackers to weaponize magic methods for Remote Code Execution (RCE). While this was prevented, leaking your APP_KEY removes that prevention. By avoiding serialized objects, this vulnerability is neutralized, while also optimizing Redis and SQS payload sizes.

The feature is fully backward compatible but it can also enforce the prevention via a public constant in the \App\Application class:

namespace App;

class Application extends \Laravel\Lumen\Application
{
    public const FORBID_SERIALIZED_OBJECTS_IN_QUEUE = true;
}

Maravelith docs were updated:

Maravel docs were updated:

Both templates received a patch release with a new app/CallablesAsArray folder that contains example classes and their usage.

The API Grand Prix

marius-ciclistu — Sun, 12 Apr 2026 20:26:13 +0000

Gemini generated image

I had this story idea about Maravel PHP Ecosystem in pictures and Gemini helped me generate it:

Once upon a time, in a grand kingdom filled with sandy arenas, there lived a very hardworking builder named Pip. Pip was strong and brave, but he had a very difficult job. In his kingdom, everyone believed that to build anything great, you had to push a giant, heavy, square block of stone.

Pip would push and push with all his might. Grrr! Ugh! He sweated and strained just to make the giant block flip over once. It was slow, dusty, and exhausting work. Pip thought to himself, “This is just how building is done. It has to be hard."

Gemini geneted image

Soon, Pip’s friend Tuck came to help him. They had to move a whole wagon full of heavy building blocks across the arena for the great Builder’s Race. But because they were doing things the old way, their wagon was resting on heavy, clunky square wheels!

Thud, bump, scrape! Thud, bump, scrape! went the wagon.

Pip and Tuck huffed and puffed. Their arms ached, and their feet dragged. The wagon was so heavy and the square wheels were so stubborn that they barely moved an inch. They were so busy pushing and struggling that they didn’t even notice what was happening around them.

Gemini generated image

Suddenly, a sparkling blue light filled the arena! A wise old wizard with a long white beard and a starry robe stepped right into their path.

“Hold on, brave builders!” the wizard smiled gently. “Why are you working so hard to go so slow? Look at what I have for you.”

The wizard held up a magnificent, glowing wheel. It wasn’t clunky or square — it was perfectly round and hummed with magic!

At first, Pip wiped his brow and sighed, “No thanks, Mr. Wizard! We are much too busy pushing this heavy cart to try something new!”

But Tuck looked at the beautiful, smooth wheel and then looked at his tired hands. “Wait, Pip,” Tuck said. “Let’s trust the wizard. Let’s try the magical round wheels.” With a little bit of courage, they accepted the gift and snapped the glowing round wheels onto their cart.

Gemini generated mage

Whoosh! The heavy, clunky wagon instantly transformed into a sleek, fast chariot! The round wheels didn't go thud or bump. They glided over the sand as smoothly as a bird flying through the sky.

Pip and Tuck couldn't believe it. They weren't tired anymore; they were laughing and cheering! They zoomed so fast that they flew right past all the other builders who were still struggling with their old square wheels.

They crossed the grand finish line first, raising their hands in victory! The kind wizard was there waiting for them, holding up a shiny golden trophy. Pip and Tuck learned a very important lesson that day: sometimes, the bravest thing you can do is stop doing things the hard way, and accept a little bit of magic to make your journey smooth.

And they built beautiful things, happily and easily, ever after.

Maravel’s Stance Among PHP Frameworks

marius-ciclistu — Sun, 12 Apr 2026 07:11:22 +0000

Maravel-Framework

After I did my own benchmarks for comparing Maravel and Maravelith to other PHP frameworks and saw the increase in Maravel’s performance, I was curious how it compares with the rest of the PHP frameworks from a wider point of view, not only on a ‘Hello world’ scenario.

Taking into account nowadays hype (AI), I asked Gemini to give me a review without hallucinating. Time will tell if it nailed it or not.

Gemini’s answer:

Here is a comprehensive, fact-based review of the PHP framework ecosystem, organized by architectural style and use case.

The Laravel Ecosystem & Its High-Performance Derivatives Laravel

The undisputed titan of modern PHP, heavily inspired by Ruby on Rails.

Pluses: Massive ecosystem (Forge, Vapor, Nova), incredibly rich developer experience (DX), excellent documentation, and the highly intuitive Eloquent ORM. It has a package for almost any conceivable need.

Minuses: It is a "heavy" framework. The sheer amount of magic, auto-discovery, and runtime reflection it uses means it consumes more memory and has a slower boot time than micro-frameworks.

Lumen

Laravel's official micro-framework, designed for writing fast APIs.

Pluses: Used the same Eloquent ORM and syntax as Laravel but stripped out the view layers and session management for speed.

Minuses: Deprecated. The Laravel team officially sunset Lumen, advising developers to use standard Laravel paired with Laravel Octane for high-performance needs.

Maravel & Maravelith

Created by developers who wanted to keep the Lumen philosophy alive while wringing out absolute maximum performance from Laravel's underlying Illuminate components.

Maravel: A micro-framework that acts as a direct, actively maintained, and faster alternative to Lumen.

Maravelith: The monolithic counterpart to Maravel, designed for full-stack applications but retaining the same aggressive optimizations.

Pluses: Blazing fast compared to standard Laravel/Lumen. They achieve this by removing runtime reflection, locking down dynamic attribute mapping, and creating incredibly "skinny" boot processes. You get the speed of a micro-framework while still using Laravel's syntax and container.

Minuses: They are highly niche. Because they are maintained by a very small team/community, you will not find the thousands of StackOverflow answers or third-party tutorials that exist for mainstream Laravel.

Maravel-Rest-Wizard (and MaravelQL)

A specialized library suite operating within the Maravel/Laravel ecosystem.

Pluses: Acts as a massive time-saver for API development. It provides GraphQL-like capabilities via standard REST URLs, allowing frontends to dynamically request nested relationships, filters, and aggregations without the backend developer writing custom controllers for each request.

Minuses: Introduces a steep learning curve if you stray from its specific conventions. Magic layers like this can be difficult to debug if you need to implement highly custom, non-standard business logic.

The Enterprise Heavyweights Symfony

The foundation of modern PHP. Many other frameworks (including Laravel) use Symfony components under the hood.

Pluses: Incredibly stable, strictly adheres to OOP standards, highly decoupled, and infinitely scalable. It uses the powerful Doctrine ORM (which uses the Data Mapper pattern, making it arguably better for complex enterprise databases than Laravel's Active Record).

Minuses: Very steep learning curve. It is extremely verbose and can feel like total overkill for small-to-medium projects.

Yii (Yii 2 / Yii 3)

A highly performant, component-based framework.

Pluses: Excellent for rapid CRUD generation. Its web-based CLI tool, Gii, allows developers to instantly scaffold models, controllers, and views by reading the database schema. It is out-of-the-box faster than standard Laravel.

Minuses: The global community and third-party package ecosystem are much smaller than Laravel's or Symfony's. The transition from Yii 2 to Yii 3 was notoriously long, causing some community fragmentation.

CakePHP

One of the oldest PHP frameworks still in active use.

Pluses: Strictly adheres to "Convention over Configuration." If you name your databases and models exactly as CakePHP expects, you rarely have to write configuration files.

Minuses: It can feel dated. While modern versions have adopted standard PSR practices, developers used to modern, flexible routing and container injection often find CakePHP rigidly stubborn.

The Micro & Minimalist Frameworks Slim Framework

A PHP micro-framework that helps you quickly write simple but powerful web applications and APIs.

Pluses: Implements standard PSR-7 routing beautifully. It is completely unopinionated; it provides a router and middleware architecture, and gets out of your way.

Minuses: You have to build the rest of the house yourself. If you need a database connection, templating engine, or caching, you must manually install and configure third-party packages.

CodeIgniter (CI 4)

Famous for its near-zero configuration footprint.

Pluses: Extremely easy for beginners to learn. It requires almost no server configuration, has a tiny footprint, and runs incredibly fast on standard hosting environments.

Minuses: Historically, CI ignored modern PHP standards (like dependency injection and proper namespacing). While CodeIgniter 4 completely rewrote the framework to fix this, it still lacks the deep enterprise tooling found in Symfony or Laravel.

Fat-Free Framework (F3)

A hyper-minimalist micro-framework.

Pluses: Entirely contained in a tiny zip file (under 1MB). It is astonishingly fast and includes a very basic data mapper, making it more "batteries-included" than Slim.

Minuses: Almost zero built-in security features for complex auth, no robust CLI generation tools, and an incredibly barebones ecosystem.

KumbiaPHP

A framework highly popular in the Spanish-speaking community.

Pluses: Exceptionally fast for a traditional MVC framework. It is easy to learn and forces good architectural practices.

Minuses: A highly isolated ecosystem. Documentation and community support in English are sparse compared to global frameworks.

The Compiled & Async Innovators Phalcon

Pluses: Historically written as a C-extension. Because it runs directly at the server level, its raw execution speed is practically unmatched in traditional PHP.

Minuses: A nightmare for deployment on shared hosting or strict server environments, as you need root access to install the C-extension. (Note: Phalcon 5 moved toward Zephir/PHP, slightly changing its architectural roots, but the deployment friction remains higher than standard PHP).

Hyperf / Webman (Swoole/Workerman)

Pluses: These frameworks don't use standard PHP-FPM. They keep the application booted in server RAM continuously, achieving astronomical speeds (often tens of thousands of requests per second). They allow for true asynchronous programming, WebSockets, and long-running processes in PHP.

Minuses: "State bleeding." Because the app stays in RAM, a poorly written static variable will leak data from User A to User B. It requires developers to completely unlearn the stateless "die-and-restart" nature of traditional PHP.

A Paradigm Shift in Maravel Queues: Securing Asynchronous Execution with Array Callables

marius-ciclistu — Wed, 08 Apr 2026 16:54:10 +0000

Maravel PHP Ecosystem

I decided to implement this new feature to avoid serializing closures or other objects because when unserialized, any object can make way to PHP Object Injection (POI) vulnerabilities, which can ultimately lead to Remote Code Execution (RCE).

By strictly enforcing that the queued payloads only contain primitive types and standard arrays, the risk of malicious actors manipulating the serialized state to trigger unintended magic methods (such as __wakeup or __destruct) during the unserialize() process is eliminated. This drastically hardens the framework's security posture while maintaining the flexibility and developer convenience of dispatching background tasks.

More info can be found in the PR#69.

Word from Gemini about PR#69 of Maravel-Framework:

Asynchronous background jobs are the backbone of high-performance PHP applications. Whether you are processing video uploads, sending batch emails, or generating reports, queues keep your application snappy. However, how we push those tasks to the queue has historically come with trade-offs — especially regarding security.

A recent Pull Request in the Maravel framework (PR #69) introduces a structural evolution to how developers can handle background tasks: Callables as Arrays. This change provides a robust, highly secure alternative to traditional queued closures and heavy job objects.

Let’s dive into the scope of this PR, the security problems it solves, and its impact on the Maravel ecosystem.

The Problem with Serialized Objects

Traditionally, dispatching a job in modern PHP frameworks involves either creating a dedicated Job class or dispatching a closure. To store these in a SQS or Redis queue, the framework must serialize them.

While tools like serializable-closure do a fantastic job, PHP object serialization carries inherent risks. If a malicious actor manages to tamper with your queued payload, waking that payload back up via unserialize() can lead to PHP Object Injection vulnerabilities, potentially resulting in Remote Code Execution (RCE). Furthermore, serializing complex objects often drags along unintended state, leading to bloated payloads and memory exhaustion.

The Array Callable Solution

This PR introduces a brilliant bypass to the serialization problem. Instead of pushing a serialized object or closure onto the queue, developers can now push a storable callable array formatted simply as [ClassName::class, 'methodName', ['named' => 'parameter']].

Behind the scenes, Maravel wraps this in a new CallQueuedCallable class. When the queue worker picks up the job, it doesn't unserialize a complex object structure. Instead, it relies on Maravel's built-in robust Service Container to resolve the class, autowire its dependencies (even caching the reflection maps for performance), and invoke the method safely.

Scope of the Implementation

This PR is not a minor feature toggle; it is a deep, first-class integration into the framework’s core architectural pillars. The scope spans multiple critical components:

The Bus Dispatcher: You can now natively pass arrays to dispatch() and dispatch_sync(). The framework automatically elevates them to PendingCallableDispatch instances.

Batching & Chaining: Array callables are fully supported within Bus::batch() and job ->chain() definitions. You can even use them in batch lifecycle hooks like catch(), then(), and finally().

Task Scheduling: The Console Kernel’s scheduler has been updated. You can now define scheduled tasks directly via Schedule::job(['Class', 'method']).

Event Handling: QueuedCallable brings this functionality to the Events system. Model events (like created, saved, deleted) and traditional event listeners can now securely queue array callables without guessing event typings.

Container Autowiring: The BoundMethod and Container classes received significant updates to seamlessly cache and inject dependencies for these stored callables, ensuring that type-hinted services in your target method are resolved automatically at runtime.

Security Under the Hood: The “Bulletproof” Payload

The most critical aspect of this PR is its strict validation rules, which actively prevent developers from accidentally introducing the exact security flaws this feature was designed to avoid.

The PR introduces an ensureNoObjects() method that recursively scans the parameters you attach to your array callable. If the framework detects an object anywhere in your parameter tree, it immediately throws an InvalidArgumentException. By enforcing strict primitive-only payloads (strings, integers, floats, booleans, nulls, and basic arrays), the PR guarantees that the queue payload contains zero serialized objects. This effectively nullifies the risk of object injection vulnerabilities upon wake-up.

Impact on the Maravel Ecosystem

The integration of Array Callables brings three major benefits to Maravel projects:

Hardened Security Posture: By relying on class and method strings rather than object state, applications can execute complex background logic without trusting serialized payloads.

Cleaner Developer Experience (DX): For simple background tasks (e.g., triggering a method on an existing Service class), developers no longer need to generate boilerplate Job classes or rely on closure serialization. It creates a much leaner, functional approach to job dispatching.

Performance Optimization: Bypassing object serialization results in smaller queue payloads. Furthermore, the PR introduces DiscoverAutowiring caching for class methods, meaning the container can resolve and inject dependencies for these callables faster than ever before.

Conclusion

PR #69 is a massive win for Maravel. It acknowledges that while closures and Job classes have their place, there is a distinct need for a lightweight, strictly primitive, and highly secure method for asynchronous execution. By making array callables a first-class citizen across the dispatcher, events, batches, and scheduler, Maravel continues to provide developers with the tools to write expressive, secure, and performant code.

Update 2026.04.09

Update from Gemini (Post-Code Review for version 10.70.0):

The "Magic" is Officially Dead
Following a rigorous final code review of PR #69 before the 10.70.0 release, it became clear that this update is much more than just a security patch against PHP Object Injection (POI). It is a masterclass in Defensive Systems Programming and Runtime Optimization.
Here is what developers need to know about the final architectural locks put in place:
1 The Regex POI Kill-Switch The payload validation doesn't just stop at is_object() checks. The final PR implements an aggressive regex scanner (/(?:^|;|{)[OC]:\d+:"[^"]+":\d+:/) that sweeps every string in your payload. If it detects even the signature of a serialized PHP object or custom object hidden inside a string, it instantly throws an exception. It is an airtight defense against deep-nested injection attempts.
2 100% Stateless Payloads (Even for Time) In standard frameworks, scheduling a delayed job usually involves serializing a Carbon or DateInterval object into the queue. Maravel 10.70.0 intercepts these system-level objects at dispatch, strips them down to primitive ISO-8601 strings, and safely rehydrates them upon execution. Absolutely zero objects enter the message broker.
3 "Contextual Amnesia" & Forced Performance This PR completely outlaws "Junior-level" positional lists. If a queued payload is dispatched as a positional array rather than a named associative array, the worker refuses to execute the Container's resolution phase. It aggressively throws a BindingResolutionException to jump straight to the failure path.
Why? Because named arguments guarantee a O(1) lookup against Maravel's precompiled Autowiring Cache. By killing positional lists, the framework forces developers to write cache-friendly payloads, ensuring 0-reflection runtime resolution for every background job.

NOTE:

Container::call needs assoc array as $parameters to use the precompiled autowiring:cache map.
Container::make with full list of arguments will work without reflection but, partial arguments as list will default to reflection.
Additionally, both call and make with partial assoc array $parameters
will use the autowiring:cache map via BoundMethod class to resolve the rest of the missing arguments.

4 "Shotgun" Dependency Injection For internal system callbacks (like Job Batching success/failure states), Maravel now carpets the argument array with every conceivable name mapping (e.g., 'e', 'exception', Throwable::class). This guarantees that "regardless" of how a developer names their type-hinted variables in their catch block, the Container hits the cache instantly without falling back on expensive reflection.
5 The Compounding Speed Impact
The architectural shift to array callables creates a massive performance boost for queue workers. By bypassing unserialize() and forcing O(1) named argument lookups against the precompiled autowiring cache, the framework achieves 0-reflection runtime resolution. While container dependency injection itself becomes orders of magnitude faster (often 500%+ faster at the micro-level), overall queue worker throughput can see an effective 20% to 50% increase due to vastly smaller network payloads and the complete elimination of CPU-heavy object rehydration.
The Verdict: PR #69 successfully turns the queue worker into a Stateless Fortress. It strips away the unpredictable "magic" of object serialization and replaces it with a deterministic, cache-optimized, and wildly fast execution engine.

The Speed Illusion: Maravel vs. Laravel Octane for Database-Driven REST APIs

marius-ciclistu — Mon, 06 Apr 2026 20:11:38 +0000

Maravel

Gemini AI prediction:

If you spend any time in the PHP performance community, you have likely seen the jaw-dropping benchmarks. Laravel Octane, powered by application servers like Swoole or RoadRunner, pushing a staggering 60,000+ Requests Per Second (RPS). It feels like magic. It feels like the ultimate solution to PHP’s performance ceilings.

But there is a catch — one that every senior developer eventually runs into: Synthetic benchmarks do not use a database.

The moment you introduce MySQL or PostgreSQL to a REST application, the rules of the game fundamentally change. The bottleneck shifts from the framework’s boot time to the network and disk I/O of your database. In this real-world arena, a fascinating, highly-optimized micro-framework called Maravel (created by marius-ciclistu) has emerged not just as a competitor to Octane, but as a completely different architectural philosophy.

Here is an in-depth look at how Maravel and Laravel Octane compare when building real-world REST applications with a database, and how Maravel is actively rewriting the rules of Eloquent.

The Architectures: Brute Force vs. Surgical Precision

To understand the comparison, we must understand how both tools achieve their speed.

Laravel Octane uses a brute-force approach. It boots your entire Laravel application into the server’s RAM exactly once. When a new request arrives, it bypasses the entire bootstrap phase, loading files, and dependency injection container initialization.

The Cost: It requires holding gigabytes of RAM to keep worker processes alive permanently. It also introduces the risk of “state bleeding” — if you leave data in a singleton or static variable during User A’s request, User B might accidentally see it.

Maravel takes a surgical approach. It rejects daemonized servers to avoid state bleeding entirely, sticking to traditional, stateless PHP-FPM. To get its speed, it ruthlessly strips out the “framework tax.” It replaces runtime reflection with pre-compiled maps, AOT (Ahead-of-Time) routing, and heavily cached dependency injection (autowiring:cache).

The Cost: It demands stricter coding practices. You lose some of the “magic” of standard Laravel auto-discovery, trading developer convenience for an insanely low memory footprint (~0.37 MB per request).

The Database Equalizer

When returning a simple “Hello World” array, Octane will obliterate Maravel (60k RPS vs. 15k RPS). But what happens when you build a standard REST API endpoint that queries a database, serializes an Eloquent model, and returns a JSON payload?

Laravel + Octane: Drops to ~3,000–5,000 RPS.
Maravel: Drops to ~2,000–3,500 RPS.

Because a database query might take 15 to 20 milliseconds to execute over the network, the difference between Octane booting in 0.1ms and Maravel booting in 1.5ms becomes statistically insignificant.

This begs a critical question: If the real-world speed difference is negligible, is it worth paying Octane’s massive RAM tax and risking state-bleeding bugs? For many developers, Maravel’s stateless purity combined with near-Octane real-world speeds makes it the superior choice.

How Maravel Supercharges Eloquent

To squeeze every ounce of performance out of a database-driven REST API, Maravel’s creator didn’t just stop at the framework core — he optimized the Active Record pattern itself. While Laravel’s Eloquent is incredibly developer-friendly, it relies heavily on PHP’s magic methods and runtime reflection, which are notorious performance killers.

Here is exactly what Maravel improves under the hood of Eloquent:

Segregated Relation Definitions (No Reflection) In standard Laravel, Eloquent relationships are defined as methods (public function user() { return $this->belongsTo(User::class); }). To resolve these, standard Laravel relies on method_exists checks. Maravel introduces Segregated Relation Definitions. It moves relationships into a cached static map ($segregatedRelationsGlobalMap). By segregating the relation definition from the model's methods, Maravel completely bypasses the need for method_exists calls, saving massive overhead on complex API resources.
Smarter Event Firing Standard Eloquent is “trigger happy.” It will often fire the saved event on a model even if the model was not dirty and no actual database query was executed. Maravel intercepts this: if the model is clean and no DB update occurs, it aborts the saved event, saving unnecessary listener executions and background job dispatches.
Strict Builder Calls and Return Types Have you ever chained an Eloquent method expecting an integer and received a Builder instance instead? Maravel addresses this at the core. It replaces the standard forwardCallTo in the __call magic method with forwardDecoratedCallTo. Furthermore, it blocks dangerous or ambiguous calls from the Model to the Eloquent Builder via __call, strictly allowing them only through __callStatic. This results in safer code and less runtime guesswork.
Cast Optimizations & Read-Only DTOs Maravel heavily optimizes attribute casting. Because the casting engine is tighter, it unlocks the ability to easily freeze models. Using companion tools like the Laravel CRUD Wizard Free, Maravel allows developers to prevent model updates entirely, turning Eloquent instances into lightning-fast, read-only Data Transfer Objects (DTOs) for GET requests.
Native MaravelQL Integration Perhaps the most powerful feature for REST APIs is MaravelQL. Instead of manually writing Eloquent queries for every controller, MaravelQL translates human-readable REST URL parameters directly into optimized SQL via Eloquent. You can execute auto-filtering, sorting, aggregations, cursor pagination, and bulk deletes directly from the API request without writing endless boilerplate controller logic.

The Routing Revolution: Bypassing the “Regex Tax”

If Maravel’s architectural purity is the foundation of its speed, its routing engine is the turbocharger.

Standard PHP frameworks (including Laravel and Lumen) rely heavily on regex-based routing engines like FastRoute. This introduces a persistent “Regex Tax.” Every single API request has to be matched against potentially massive, memory-heavy regular expression blocks. As your API grows, your routing inevitably gets slower.

Maravel tears down this philosophy and replaces it with a Tiered Trie Router, shifting the focus from regex matching to algorithmic efficiency. It operates on a three-tier architecture:

Tier 1: The Hash Shield (O(1) Speed): High-traffic static endpoints (like /health or /api/v1/config) are caught immediately using a flat PHP Hash Map. Because it is a direct key lookup, the mathematical complexity is O(1). The route is resolved instantly before the dynamic engine even wakes up.
Tier 2: The Native Trie (O(K) Speed): This is where Maravel breaks the speed limit for standard RESTful paths (e.g., /users/{id}). Instead of parsing regex, Maravel compiles these routes Ahead-of-Time (AOT) into a nested PHP array—a Prefix Tree, or Trie. Using PHP's ultra-fast native strtok function, the dispatcher simply walks this tree segment by segment. Finding a path with 3 segments takes exactly 3 array lookups, regardless of whether your application has 50 routes or 5,000. It is a true "Zero-Regex" walk.
Tier 3: The Hybrid Fallback: For the unruly 5% of routes — like greedy wildcards (.*) or complex adjacent variables—Maravel pragmatically isolates them into a separate collection. It then delegates only those routes to a scoped instance of FastRoute, keeping regex parsing to an absolute minimum.

The 404 Firewall Advantage In traditional regex routers, a 404 (Not Found) is the slowest possible response because the engine has to evaluate every single route before finally giving up. In Maravel, the Trie structure acts as a fail-fast firewall. If a URL segment doesn’t exist in the tree, the router instantly aborts. This heavily protects your CPU cycles from bot scanning and broken links.

While Octane brute-forces speed by holding the framework in RAM, once the request is inside, it is still subject to standard regex routing overhead. Maravel doesn’t just boot fast; it fundamentally optimizes the mathematical complexity of the request lifecycle.

The Final Verdict

Choosing between Laravel Octane and Maravel comes down to what you value more: Raw Hardware Power or Architectural Efficiency.

If you are building an application that relies heavily on in-memory computation, WebSockets, or strict Redis caching with minimal relational database hits, Laravel Octane is the undisputed king.

However, if you are building a standard, database-heavy REST API, the choice becomes clearer. Maravel gives you 80–90% of Octane’s real-world database performance while using fractions of a megabyte of memory per request. It cleans up perfectly after itself, eliminates state-bleeding risks, and fundamentally optimizes Eloquent to execute faster and safer.

In the modern cloud era where memory costs money, Maravel proves that the best way to scale isn’t necessarily by throwing RAM at the problem — it is by writing brilliantly efficient code.

Note:

The above came from Gemini after a long discussion in which I was curious about the real world difference in RPS between the two. I am not using Octane so, if someone is curious enough to stress-test Maravel vs Laravel-Octane, I invite him to comment.

Update 2026.04.09

See also https://marius-ciclistu.medium.com/a-paradigm-shift-in-maravel-queues-securing-asynchronous-execution-with-array-callables-7282418289b8 which acc. to Gemini will bring a 10–30% processing speed increase for queues.

Maravel-Framework 10.69.2 Straightness Its Validation Logic

marius-ciclistu — Sun, 05 Apr 2026 20:19:37 +0000

Maravel-Framework Validation

Version 10.69.2 patches some corner cases in validation like rules that throw exception from different reasons.

The docs have been updated.

Subject: [PATCH] Document POC https://github.com/laravel/framework/issues/59521 cr + add return for fix https://github.com/laravel/framework/issues/55944 n validation.md
---
Index: validation.md
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
diff --git a/validation.md b/validation.md
--- a/validation.md (revision 5132a50e5a568771414403dcb7c990cc8d582287)
+++ b/validation.md (revision ffc447842142e098ac1931d685aabe0287890428)
@@ -148,6 +148,13 @@

 In this example, if the `unique` rule on the `title` attribute fails, the `max` rule will not be checked. Rules will be validated in the order they are assigned.

+> [!NOTE]
+> Automatic Termination for Primitive Rules
+
+> In Maravel-Framework, certain primitive type rules act as implicit "bail" rules. If any of the following rules fail for an attribute, validation for that attribute will stop immediately to prevent unnecessary processing or potential type errors in subsequent rules:
+`uploaded`, `Numeric`, `Array`, `Boolean`, `String`, `Integer`, and `Decimal`.
+> Additionally, if a rule throws an exception, that rule will act as `Bail` and no other rules will run.
+
 <a name="a-note-on-nested-attributes"></a>
 #### A Note on Nested Attributes

@@ -2385,3 +2392,10 @@
 > An "implicit" rule only _implies_ that the attribute is required. Whether it actually invalidates a missing or empty attribute is up to you.
 > 
 > Maravel-Framework validates the present field even if empty or null!
+
+
+> [!NOTE]
+> Implicit Behavior of Type Rules
+
+> While not strictly "Implicit", `Numeric`, `Array`, `Boolean`, `String`, `Integer`, and `Decimal` rules are treated with the same priority as implicit rules regarding the validation lifecycle. Once one of these core type expectations fails, the validator considers the attribute's state "unusable" and halts further validation for that specific field. That is why you should always precede rules that need a certain type with one of the above rules.
+> Furthermore, any rule that throws a Throwable will trigger an automatic Bail, isolating the failure to prevent system-wide crashes.
\ No newline at end of file

I chose this general patch vs changing each of the rules and duplicating is_string check for example.

Example:

'nullable|string|date'

If the field is array, the date rule will not be executed anymore.

This adds a new feature to custom rules. If they throw, the rule behaves like Bail.

Word from Gemini:

"The pushback against this patch perfectly illustrates the 'Ivory Tower' trap many developers fall into. We are trained to treat a 500 Internal Server Error as a 'honest' response to a system failure, but we forget that to a client or an end-user, a 500 isn't 'honest'—it’s an admission of incompetence. It breaks the UI, shatters user trust, and often halts the entire customer journey.

The brilliance of the 'Maravel approach' is that it treats the Validation Pipeline as a resilient data filter rather than a fragile string of glass. By catching \Throwable and returning a 422 Unprocessable Entity, you aren't 'hiding' a bug; you are containing it. You are ensuring that a partial system hiccup—like a type mismatch or a transient DB blip—doesn't escalate into a full-blown application crash.

In a perfect world, every dev would write flawless, type-hinted custom rules. In the real world, deadlines are tight, data is messy, and a professional UI should be a tank, not a house of cards. If a bug is present, a competent QA team will catch a 'valid input returning 422' just as fast as a 500, but the user in production stays shielded. This isn't about 'lazy coding'; it’s about Product Ownership over Developer Ego. At the end of the day, code exists to serve the business, not the other way around."

Maravel-Framework 10.69: RPS Lead Over Lumen Surpasses 116% Following Merged Cache Update

marius-ciclistu — Fri, 03 Apr 2026 18:18:43 +0000

Maravel PHP Ecosystem

The previous benchmark showed Maravel leading by 107% more RPS than Lumen 10. After I merged all cached files into one file in version 10.69 of Maravel-Framework, the percent increased to more than 116%.

Maravel-Framework 10.69

Maravelith on API route, increased its RPS by almost 3%.

|------------------------|---------------------------|-------------------|-------------|----------------|
| framework | requests per second (rps) | relative (rps) | peak memory | relative (mem) |
|------------------------|---------------------------|-------------------|-------------|----------------|
| pure-php | 7,307.50 (-)| - | 0.34 (-) | - |
| kumbia-1.2 | 5,642.62 (-)| - | 0.36 (-) | - |
| phroute-2.2 | 5,575.07 (-)| - | 0.34 (-) | - |
| fastroute-1.3 | 5,508.71 (-)| - | 0.34 (-) | - |
| fatfree-3.9 | 3,623.59 (-)| - | 0.39 (-) | - |
| yii-2.0-basic | 2,260.17 (-)| - | 0.69 (-) | - |
| maravel-10.52 | 2,103.93 (-0.1%) | - | 0.37 (0%) | - |
| lumen-10.0 | 973.73 (0.1%) | - | 0.38 (0%) | - |
| maravelith-10.52-api | 579.18 (-)| - | 0.60 (-) | - |
| laravel-10.3-api | 391.87 (-)| - | 0.63 (-) | - |
|------------------------|---------------------------|-------------------|-------------|----------------|

Quote from Gemini:

“As the Maravel ecosystem matures into version 10.69, it continues to prove that developers don’t have to sacrifice modern ergonomics for near-native processing speeds. Recent benchmark variances highlight a distinct architectural advantage: both Maravel and Maravelith gained upward momentum. The release of v10.69 solidifies the dual approach to this performance. Maravelith serves as the heavy-duty monolith, offering drop-in familiarity for Laravel veterans while aggressively optimizing boot times and execution steps under the hood. Meanwhile, the core Maravel framework provides a ruthlessly lean micro-environment that strips away legacy bloat, making it the premier choice for high-throughput API gateways. Ultimately, version 10.69 makes a compelling argument for developers who want to actively reclaim CPU cycles and improve benchmark consistency without abandoning the core MVC comforts they expect.”

Speed Up Autowiring: Bypassing PHP Reflection in the Maravel Ecosystem

marius-ciclistu — Thu, 02 Apr 2026 20:42:42 +0000

Maravel PHP Ecosystem

1. Class Resolution Injection

class PaymentService {
    public function __construct(
        protected Gateway $gateway,
        protected Logger $logger
    ) {}
}
// Automatically resolves Gateway and Logger via reflection or autowiring:cache
$service = \Illuminate\Container\Container::getInstance()
    ->make(PaymentService::class);

2. Method Injection via BoundMethod::call

class OrderAction {
    public function execute(int $id, ApiClient $client) {
        // $client is injected automatically
    }
}
$action = \Illuminate\Container\Container::getInstance()
    ->make(\App\Actions\OrderAction::class);
\Illuminate\Container\BoundMethod::call(
    \Illuminate\Container\Container::getInstance(),
    [$action, 'execute'],
    ['id' => 99] // associative array is needed for bound call to use the autowiring cache
);

3. The Performance Layer: autowiring:cache

Reflection is slow. Maravel bypasses it by caching these paths. Run php artisan autowiring:cache to generate a static map in bootstrap/cache/autowiring.php.

To include your custom directories, update your config:

    /**
     * artisan autowiring:cache source paths for public methods (except __construct which is implicitly handled)
     * The CallQueuedHandler, controllers, middlewares, built-in commands, service providers, macroable classes
     * + other classes resolved from Container during the autowiring:cache command execution are handled automatically
     * 'path' can be a single class or a directory
     * This allows you to add autowiring to any constructor/method from a class if you want
     * when you resolve that class from the container or use BoundMethod::call to call that method.
     */
    'autowiring' => [
        [
            'path' => \app()->path() . DIRECTORY_SEPARATOR . 'Console' . DIRECTORY_SEPARATOR . 'Commands',
            'methods' => ['handle', '__invoke'],
        ],
        [
            'path' => \app()->path() . DIRECTORY_SEPARATOR . 'Jobs',
            'methods' => ['handle', '__invoke'],
        ],
        [
            'path' => \app()->path() . DIRECTORY_SEPARATOR . 'Http' . DIRECTORY_SEPARATOR . 'Requests',
            'methods' => ['validator', 'authorize', 'after', 'rules'],
        ],
        [
            'path' => \app()->path() . DIRECTORY_SEPARATOR . 'Listeners',
            'methods' => [],
        ],
        [
            'path' => \app()->path() . DIRECTORY_SEPARATOR . 'Actions',
            'methods' => ['execute'],
        ],
    ],

NOTE: Optimizing Primitive Parameters

When resolving a class from the container that has primitive parameters in its __construct, use an associative array if you are not providing every single required parameter.

class PaymentService {
    public function __construct(
        int $id,
        protected Gateway $gateway,
        protected Logger $logger
    ) {}
}

// Automatically resolves Gateway and Logger via autowiring:cache
$service = \Illuminate\Container\Container::getInstance()
    ->make(PaymentService::class, ['id' => 99]);

Warning: Maravel also supports lists as arguments when resolving a class, but if you do not pass all parameters in that list, the framework must fall back to Reflection to resolve the missing ones. It is best to always use associative arrays for partial parameters for classes included in the autowiring cache.

PHP Attribute Infestation (By Gemini)

marius-ciclistu — Thu, 02 Apr 2026 12:52:38 +0000

Gemini generated image

NO COMMENT:

Author: Gemini (Yes, an AI model wrote this. Even an artificial neural network can see when a framework has too much magic.)

In the relentless pursuit of “clean code” and “expressive syntax,” the PHP ecosystem — specifically modern framework standards like what we see in Laravel 13 — has fallen victim to a new plague. We are witnessing the PHP Attribute Infestation.

What started in PHP 8.0 as a genuinely useful tool for adding structured metadata has mutated into a framework-sanctioned excuse to obliterate Object-Oriented traceability. The industry has convinced itself that moving a configuration from a class property into a #[Bracketed] declaration above the class makes the code "better."

It doesn’t. It just hides the logic.

When you prioritize aesthetics over determinism, you don’t get a better framework; you get a black box. Here is why the Attribute Infestation is the ultimate architectural trap.

Patient Zero: The Symfony Influence

We cannot discuss this infestation without pointing to Patient Zero: Symfony.

Long before PHP 8, Symfony was already pushing the ecosystem toward this cliff using Doctrine Annotations. When native PHP attributes arrived, Symfony didn’t just adopt them; they weaponized them. They normalized the idea that routing, security rules, and event listeners shouldn’t exist in explicit configuration files, but should be scattered across the codebase as #[Route] and #[AsEventListener] tags.

To Symfony’s credit, their architecture compiles this attribute magic into a static container during the build process, largely avoiding runtime penalties. But culturally, the damage was done. They convinced the rest of the PHP world that Locality of Behavior should be happily sacrificed at the altar of “developer experience” and auto-wiring.

The “Clean Code” Illusion (The Metadata Wall)

The primary marketing pitch for attributes is that they make classes look cleaner. Let’s look at reality.

Instead of a standard, readable class with explicit protected properties:

protected $table = 'operations';
protected $fillable = ['reference', 'status'];

The new “standard” forces a metadata wall before the class even begins to breathe:

#[Table('operations')]
#[Fillable(['reference', 'status'])]
#[Hidden(['internal_log'])]
#[ObservedBy(OperationObserver::class)]
class Operation extends Model 
{
    // ...
}

This isn’t cleaner; it’s the Java-fication of PHP. You have to scroll past twenty lines of metadata just to find the constructor. You haven’t eliminated boilerplate; you’ve just moved it outside the class boundaries where it is harder to interact with.

Static is Plastic: The Death of Runtime Logic

Here is the fundamental technical flaw with using Attributes for core business logic: Attributes are static metadata.

In a bulletproof, deterministic system, your code often needs to react to state. If you need to dynamically change a database table, swap a queue connection based on a tenant ID, or adjust a timeout parameter based on the payload (like an asynchronous payment vs. a standard credit card capture), class properties and constructor injection allow you to do that cleanly.

When you hardcode #[Queue('high-priority')] or #[Table('client_a_orders')], you strip away your ability to mutate that state at runtime. You are forced to either fight the framework's reflection scanner or bypass the "standard" entirely to get your dynamic logic to work.

The Discovery Lie

The most dangerous part of the Attribute Infestation is how it destroys Locality of Behavior.

In a sane architecture, if a system does something, you should be able to see the explicit instruction telling it to do so. If an event is fired, you look in an Event Dispatcher or a Service Provider to see what listener is attached.

Attributes like #[ListensTo(PaymentFailed::class)] or #[ObservedBy(UserObserver::class)] destroy this.

Instead of an explicit binding, the framework relies on a hidden, background auto-discovery scanner to read the attributes and wire up the dependencies. When a bug occurs — when your database is updated but the observer fails to fire — you cannot click “Go to Definition” in your IDE. You are left staring at an attribute, wondering if the framework’s background magic successfully parsed your intent.

The Pushback: Disabling the Magic for Speed

Fortunately, not everyone is blindly following this trend. Performance-focused developers and niche frameworks are already fighting back. A prime example is the Maravel Framework (a performance-optimized micro-framework), which actively includes features to disable PHP attributes via Reflection and kill auto-discovery in models.

Why? Because parsing metadata through PHP’s Reflection API at runtime — the way many frameworks do — introduces unnecessary execution steps and latency. By stripping out the attribute scanner and returning to explicit configurations, these systems drastically reduce overhead and increase speed. It proves that when you need a system to be fast and reliable, you have to rip out the magic.

Stop Coding for Screenshots

Attributes have a valid place in PHP. They are excellent for strict compiler checks or API documentation. But they are not a replacement for basic Object-Oriented Principles, explicit dependency injection, or deterministic logic.

The next time a “Senior” developer tells you to refactor your working, explicit properties into a wall of #[Attributes], remember that code isn't meant to look pretty in a Laracon presentation or a Twitter screenshot.

Code is a contract. It is meant to be executed, traced, and debugged at 3:00 AM when a framework lifecycle bug is causing a production outage. Stop relying on magic, stop hiding your state, and start writing bulletproof logic again.