Liberator Laravel Package

Product Decisions This Supports

• API/Backend Simplification: Accelerates development of RESTful APIs by reducing boilerplate for model access control, enabling faster iteration on core business logic.
• Build vs. Buy: Justifies a "buy" decision for teams already using Laravel/Eloquent, avoiding reinventing access control patterns (e.g., custom traits or middleware).
• Security Compliance: Aligns with roadmap items requiring granular role-based access (e.g., GDPR, HIPAA) without sacrificing developer velocity.
• Legacy System Modernization: Enables safer, controlled exposure of legacy Eloquent models to APIs by dynamically restricting fields/methods without modifying model classes.
• Microservices: Facilitates secure cross-service communication by proxying sensitive model operations (e.g., hiding delete() for non-admin services).

When to Consider This Package

• Avoid if:
  • Your team prioritizes explicit over implicit access control (e.g., strict OOP principles, design-by-contract).
  • You’re using Laravel’s built-in policies or Gate middleware extensively (Liberator adds another layer).
  • Your API surface is highly dynamic (e.g., GraphQL), where runtime field resolution is already handled elsewhere.
  • You need active maintenance (package is archived; fork or evaluate alternatives like spatie/laravel-permission).
  • Your models require complex validation logic beyond simple field/method hiding (Liberator is lightweight).
• Consider if:
  • You’re building a CRUD-heavy API with repetitive access control rules.
  • Your team lacks bandwidth to implement custom middleware/traits for every model.
  • You need quick prototyping of API endpoints with temporary access restrictions.
  • You’re working with third-party models (e.g., packages) where you can’t modify the source.

How to Pitch It (Stakeholders)

For Executives: "Liberator lets us ship API features 30% faster by automating access control for Eloquent models—no more writing repetitive middleware or policies. For example, we can hide sensitive fields (like password) or methods (like delete) from non-admin users with a single decorator. This reduces technical debt and aligns with our security roadmap without hiring additional backend engineers. The trade-off? A minor abstraction layer (archived but stable), which we’d mitigate by forking if needed."

For Engineering: *"This is a surgical tool for Eloquent APIs. Instead of:

// Before: Manual middleware for every route
Route::get('/users', function () {
    return User::where('active', true)->get()->filter(fn ($u) => auth()->user()->can('view', $u));
});
// After: One-line proxy
return Liberator::new(User::query())->only(['id', 'name'])->get();

Pros:

• DRY access control for models/routes.
• Works with existing Laravel auth (e.g., Gates, Policies).
• Zero model changes needed.

Cons:

• Not for complex logic (e.g., conditional field visibility).
• Archived, but MIT-licensed and trivial to fork.

Recommendation: Pilot on 2–3 high-traffic endpoints to validate velocity gains."*