`$fillable` doesn't know if it's the admin panel or the customer API calling `Order::create()` - so fields like `is_forced_processing` or `is_from_api` are equally "allowed" for everyone. This post explains why mass assignment breaks down in large Laravel projects and how the DTO + Action pattern fixes it.
dev.to/tegos/fillable-has-no-context-why-mass-assignment-breaks-down-at-scale-3lmj
Ever stared at a 50k row export and thought "are my enums slowing this down?"
I did. So I rewrote the whole thing to use pre-cached arrays instead of tryFrom() on every row, moved JSON decoding to raw SQL, and benchmarked both versions carefully.
Result? 16ms difference. Literally noise.
Turns out PHP 8.1 enums are singletons - same instance every time, no allocations, no GC pressure. Your real bottleneck is I/O and formatting, not enums.
Use tryFrom(), this is fine.
dev.to/tegos/php-enums-are-not-your-bottleneck-heres-proof-1887
Ever wonder why that trait seemed like a good idea until you needed to test it?
Traits in PHP look convenient at first, but they hide dependencies, break encapsulation, and make your code harder to understand.
I wrote about why I avoid traits and what works better: dependency injection, composition, and simple classes.
Real dependencies should be visible in the constructor, not burried in protected methods.
The rule is simple: if behavior can be extracted into a seperate object, it should be.
dev.to/tegos/why-i-avoid-php-traits-and-what-i-use-instead-1288
Ever struggled with factory relationships when two fields point to the same model? Turns out Laravel isn't guessing wrong, it's following its rules perfectly.
When you use `for($owner)` and `for($distributor)`, Laravel looks at model TYPE, not variable names. Both are Users, so it picks the first relationship and ignores the rest.
The fix? Be explicit: `->for($owner, 'user')` or just set foreign keys directly - I usually prefer that.
My take on @jclermont great insight. Sometimes being explicit beats magic.
dev.to/tegos/why-laravel-cant-guess-your-factory-relationships-4keb
Ever had a test pass locally but fail randomly in CI? That's what happened to me when testing timestamp fields.
The issue? Date::now() gets called twice - once in your code, once in your test - and those milliseconds add up.
The fix is simple: freeze time with Date::setTestNow() or $this->freezeTime() before making requests.
No more flaky tests, just reliable assertions.
dev.to/tegos/stop-flaky-tests-freeze-time-in-laravel-testing-1cnj
•
Yeah, nice.
When you use Date::now(), this can be simply configurable via provider, like Date::use(CarbonImmutable::class).
•