Folio Laravel Package

Product Decisions This Supports

• Decoupled Frontend Architectures: Enable page-based routing for JAMstack/Laravel hybrid apps (e.g., static pages served via Folio + dynamic APIs). Reduces reliance on traditional Laravel route files for static content, aligning with modern frontend frameworks (e.g., Next.js, Nuxt) that prefer file-system routing.
• Build vs. Buy:
  • Buy for teams needing database-driven routing without the overhead of a full CMS (e.g., WordPress, Strapi). Folio’s lightweight design avoids vendor lock-in while offering more flexibility than static site generators.
  • Build only if requiring highly customized route logic (e.g., real-time validation, non-file-system-based page hierarchies) or integrating with niche Laravel ecosystems (e.g., custom Eloquent behaviors).
• Roadmap Priorities:
  • Short-Term: Replace manual route definitions in marketing sites or documentation portals with Folio’s folio:install CLI, reducing onboarding time for content editors.
  • Mid-Term: Integrate with Laravel Livewire or Inertia.js for dynamic page previews in admin panels (leveraging Folio’s ViewMatched events).
  • Long-Term: Extend to multi-tenant SaaS via Folio’s domain support (e.g., tenant1.app.com/pages/about).
• Use Cases:
  • Headless CMS: Serve static pages via Folio while using Laravel as an API backend (e.g., Next.js frontend + Folio-powered /blog routes).
  • Progressive Web Apps (PWAs): Cache Folio routes aggressively for offline-first experiences (combine with Laravel’s route:cache).
  • Localization: Route pages by language (e.g., /en/about, /es/sobre-nosotros) using Folio’s domain/middleware features.
  • A/B Testing: Store page variants in a folio_page_versions table and dynamically route users via Folio’s render() method.

When to Consider This Package

• Adopt Folio if:

  • Your application relies on file-system-based routing (e.g., resources/views/pages/**/*.blade.php) and you want to centralize page management in a database.
  • You’re building a content-heavy app (e.g., blogs, marketing sites, wikis) where pages are frequently updated by non-technical users.
  • You need multi-domain or multi-language support without writing custom route logic (Folio handles this via middleware and domain configurations).
  • Your team prefers Laravel-native solutions over third-party CMS platforms (e.g., WordPress, Craft CMS) for tighter integration with Eloquent, Livewire, or Nova.
  • You’re migrating from hardcoded routes to a more scalable, database-driven approach and want to avoid reinventing routing logic.
  • Your app uses static pages (e.g., landing pages, legal disclaimers) that could benefit from versioning or A/B testing via Folio’s render() method.

• Avoid Folio if:

  • Your routing logic is highly dynamic or non-hierarchical (e.g., API-only apps, real-time WebSocket routes). Folio is optimized for page-based (file-system or database-driven) routing.
  • You require complex route constraints (e.g., regex-based matching, custom middleware chains per route) that exceed Folio’s built-in capabilities. Consider Laravel’s native router or packages like spatie/laravel-routing.
  • Your team lacks Laravel familiarity—Folio assumes knowledge of Laravel’s service container, Eloquent, and Blade templating.
  • You need multi-tenancy at the route level (e.g., tenant1.app.com/* vs. tenant2.app.com/*). Folio’s domain support is basic; consider spatie/laravel-multitenancy for advanced use cases.
  • Your app is API-only with no frontend or minimal static content. Folio adds unnecessary complexity for backend-heavy applications.

How to Pitch It (Stakeholders)

For Executives (Business/Strategy)

*"Folio lets us launch content-driven features faster—like marketing sites, blogs, or internal wikis—without hiring a full-stack developer for every new page. By moving from hardcoded routes to a database-backed system, we reduce technical debt and empower non-technical teams to manage content directly. For example:

• Marketing: Launch a new landing page in hours, not days, by letting designers upload Blade templates and copy.
• Localization: Support /en, /es, etc., without rewriting routes for each language.
• Cost Savings: Avoid licensing fees for third-party CMS platforms while keeping the flexibility of Laravel. This aligns with our goal of scaling content operations without scaling engineering headcount."*

Ask: "Which of our current projects would benefit most from dynamic, database-driven pages? (e.g., customer portals, documentation, or product pages?)"

For Engineering (Technical)

*"Folio is a Laravel-native, file-system-to-database routing solution that:

1. Replaces manual routes/web.php definitions for static/dynamic pages with a folio_pages table, reducing boilerplate.
2. Integrates seamlessly with Laravel’s ecosystem:
   • Works with Blade, Livewire, and Inertia.js out of the box.
   • Supports middleware, domain routing, and event listeners (e.g., ViewMatched).
   • Compatible with Laravel 11–13 and PHP 8.4–8.5.
3. Accelerates development:
   • CLI commands (folio:install, folio:list) for scaffolding and debugging.
   • Database-driven URL generation (e.g., route('page.show', $page)).
   • Built-in support for nested routes, slugs, and versioning.
4. Future-proof:
   • Extendable for multi-tenancy, A/B testing, or admin panel integration (e.g., Nova).
   • Lightweight (~50KB) with no external dependencies.

Proposal:

• Phase 1: Replace static routes (e.g., /about, /careers) in [Project X] with Folio. Estimated effort: 2–3 dev days (installation + migration).
• Phase 2: Add localization support for [Project Y]’s multi-language requirements.
• Phase 3: Integrate with Nova for content editors to manage pages via UI.

Risks:

• Minimal—Folio is battle-tested by the Laravel team and used in production (e.g., Laravel’s own docs).
• Migration effort is one-time; long-term savings in maintenance and scalability.

Ask: "Which of our current route-heavy features could we refactor to use Folio? Let’s prioritize the highest-impact pages first."