Now you can define your relations like this, in one place in your model:
// model protected function segregatedRelationsDefinitionMap(): array { return [ 'relName' => fn(): HasOne => $this->hasOne(Model::class, 'model_id', 'id'), // Reuse the segregatedrelation inside another segregated relation: 'relNameScoped' => fn(): HasOne => $this->relName()->where('col', '=', 'text'), 'relNameScoped2' => fn(): HasOne => $this->callSegregatedRelation('relName')->where('col', '=', 'text'), // Reuse the method relation: 'relNameAsMethod' => $this->relNameAsMethod(...), 'relNameAsMethod' => fn(): HasOne => $this->relNameAsMethod(), // AVOID THIS BECAUSE IT IS NOT Closure and it will not work: 'relNameAsMethod' => [$this, 'relNameAsMethod'], // AVOID THIS 'relNameAsMethod' => fn(): HasOne => [$this, 'relNameAsMethod'](), // DO NOT USE IT LIKE THIS!: 'relNameAsMethod' => fn(): HasOne => $this->relNameAsMethod(...)(), // executes the relation inside the map. ]; }
And get the whole list by calling segregatedRelationList:
/** * Get the list of all currently identified relationship keys. * * This list includes: * 1. Explicitly defined relations from * @see segregatedRelationsDefinitionMap() * 2. Implicit method-based relations that have been "promoted" to the global * static map via @see resolveSegregatedRelationClosure() * * @param bool $discoverMethods If true, performs a one-time SLOW REFLECTION scan to identify and * promote all typed relationship methods to the global map. * * @note This list is usage-dependent when $discoverMethods is false. If true, the static * map is force-populated for the remainder of the request lifecycle. * THE FASTEST WAY for execution is to refactor all method relations by moving them into that map or * manually promote all method relations to segregated relations via: * @see segregatedRelationsDefinitionMap() * return [ * 'relNameAsMethod' => $this->relNameAsMethod(...) * ] * * @return string[] */
final public function segregatedRelationList(bool $discoverMethods = false): array
{ if ($discoverMethods) { $this->promoteMethodRelationsToSegregatedRelations(); } return \array_keys($this->thisSegregatedRelationDefinitionMap());
}
Challenged by this discussion which proposes PHP attributes for the relation definition to avoid the method definition issues that arise for identifying if a method is relation or not in an active record, after this PR you can segregate the relation definition from the model s methods without using Reflection.
This was the missing piece after version 10.64.14 of Maravel-Framework brought full view support to Maravel, including view:cache, session (CSRF), cookie and FormRequest.
domain keyword can be used as single valid url or as list of valid urls.
The global helper function route( alias ) will return full URLs instead of URIs.
Maravelith API vs WEB RPS increased by 90% and memory decreased by 3% after I converted View, Cookie and Session service providers into deferred providers in version 10.64.14 of Maravel-Framework that also brought full view support to Maravel as well, including view:cache, session (CSRF), cookie and FormRequest.
As mentioned here, it is not fair to compare Maravelith WEB with Maravel API or Laravel WEB with Lumen API routes. Analog for any php micro-framework that is compared with full framework. Comparisons should be done on API vs API because the session middleware brings an important slow down on the web routes.
After version 10.64 introduced the FormRequest to Maravel, version 10.64.8 brings Session and Cookies support also as OPT IN.
The reason for this feature is that you might need to use csrf tokens and/or cookies in your views WITHOUT migrating to Maravelith and trading boot speed just for that.
Because Maravel-Framework is a DI centered framework, the efficiency of its container is crucial.
Version 10.64 introduces FormRequest in Maravel Micro-Framework 10.52.25.
Version 10.64 of Maravel-Framework removed the \Illuminate\Foundation\Providers\FormRequestServiceProvider, leading to faster registration and boot times.
Please note that using $app-beforeResolving, $app->resolving or $app->afterResolving events, the speed of the container decreases because for each resolve, all events are looped to search via === or instanceof/is_subclass_of for the ones that need to be triggered.
Versions 2.0.0 of laravel-crud-wizard-decorator-free and version 7.1.0 of laravel-crud-wizard-free introduce an important response time improvement by eliminating useless json_decode and json_encode calls between the controller and the middlewares.
Because the controller resolves the JsonResponse from DI, the CrudProvider registers a binding for it in which the json_encode is skipped when the data needs decoration.
This follows Maravel-Framework s design of DI first logic and it works also in Laravel and Lumen.
Because I dislike runtime reflection, I improved the autowiring:cache command to include also constructors, not just methods.
If the concrete has contextual bindings (and constructor parameters) the old reflection is still used.
If the parameters are sent as array list, concrete will be instantiated directly with them. On failure, it will default to the old reflection but at the cost of building an Exception.
Last night at 8:50 PM, I sat down to rebuild a product's backend from scratch. By 11 PM, I had a complete Laravel API with auth, CRUD, real-time WebSockets, and chat. By 1:50 AM, the existing React Native frontend was wired up and running against it locally. Deployed to the cloud the next morning.
That's about two hours for the entire backend. Five hours total including frontend integration.
Here's how multi-agent orchestration, Laravel, and solid documentation made that possible.
Version 10.55.0 lost ~10.8 k rows of dev environment code that was moved to a separate package. https://marius-ciclistu.medium.c...
Version 10.56.0 brings faster boot time for apps that have many listeners for events and/or observers by improving the way they are registered, including caching the observers when events are cached. https://marius-ciclistu.medium.c...
Maravel-Framework 10.54.3, which is used in Maravel Micro-Framework and Maravelith Template, restricts the devCommands to local environment and by doing this, it speeds up the boot of the application. Also it contains a back-port for \Illuminate\Console\Prohibitable with the mention that these classes are by default prohibited from running in production:
Maravel 10.51.4 can process woth 15.965% more requests per second vs Lumen 10. This is without caching for config or routes and without opcache preload. More details https://github.com/myaaghubi/PHP...
Version 5.1.0 of laravel-crud-wizard-free will include a backward compatible (laravel >= 8) major performance improvement for reducing the number of set calls during updates when using casts. Also a new feature of locking the model to prevent updates will come as a bonus. Maravel-Framework 10.53.2 will also contain this improvement at a larger scale than the one possible via an external package. It will support prevention of updates also. More details .
Most people think users choose products based on features or price. In reality, support decides who stays.
A cheaper tool becomes expensive fast when every issue turns into a ticket nightmare. Meanwhile, teams keep paying more for products that solve problems and support them when it matters.
Support is not a cost. It is part of the product experience. Fast replies build trust. Clear answers reduce churn. Companies that treat support as a growth lever win.
Most people think users choose products based on features or price. In reality, support decides who stays.
A cheaper tool becomes expensive fast when every issue turns into a ticket nightmare. Meanwhile, teams keep paying more for products that solve problems and support them when it matters.
Support is not a cost. It is part of the product experience. Fast replies build trust. Clear answers reduce churn. Companies that treat support as a growth lever win.
