Laravel selama ini identik dengan pendekatan routing eksplisit melalui file seperti routes/web.php dan routes/api.php. Pola ini matang, fleksibel, dan sangat familiar bagi banyak tim. Namun, Laravel Folio memperkenalkan pendekatan lain: file-based routing, yaitu route diturunkan langsung dari struktur file pada direktori tertentu, mirip pola yang populer di framework frontend modern.

Pertanyaan pentingnya bukan apakah Folio lebih modern, melainkan kapan ia benar-benar layak dipakai. Untuk menjawab itu, kita perlu memahami bagaimana Folio bekerja, bagaimana ia menangani parameter route, middleware, layout, dan integrasi dengan Blade, lalu membandingkannya secara kritis dengan routing klasik Laravel dari sisi keterbacaan, skalabilitas, testing, dan kerja tim.

Apa Itu Laravel Folio dan Bagaimana Cara Kerjanya?

Folio adalah paket resmi Laravel untuk membangun halaman dengan routing berbasis file. Intinya sederhana: file Blade pada direktori Folio dipetakan menjadi endpoint HTTP. Struktur folder berperan sebagai deklarasi URL.

Misalnya, jika Anda memiliki file berikut:

resources/views/pages/index.blade.php
resources/views/pages/about.blade.php
resources/views/pages/users/index.blade.php

Maka secara konseptual ia dapat dipetakan menjadi:

  • / -> pages/index.blade.php
  • /about -> pages/about.blade.php
  • /users -> pages/users/index.blade.php

Dari sudut pandang pengembang, ini membuat halaman sederhana menjadi lebih dekat ke struktur URL. Anda tidak perlu mendeklarasikan route satu per satu untuk setiap halaman informasional atau halaman CRUD ringan yang sangat berorientasi tampilan.

Pendekatan ini bekerja baik ketika:

  • sebagian besar halaman adalah render Blade biasa,
  • struktur URL relatif stabil dan mudah dipetakan ke folder,
  • Anda ingin mengurangi kepadatan file route,
  • aplikasi memiliki banyak halaman konten atau dashboard yang sederhana.

Namun, Folio bukan pengganti total router Laravel. Ia lebih tepat dipahami sebagai lapisan routing alternatif untuk use case tertentu, bukan solusi universal bagi seluruh aplikasi.

Instalasi dan registrasi dasar

Secara umum, Anda menginstal Folio melalui Composer lalu mendaftarkan direktori halaman yang akan dipindai. Detail bootstrap bisa sedikit berbeda tergantung struktur proyek, tetapi pola penggunaannya tetap sama: ada direktori khusus, dan Folio akan memetakan file di dalamnya menjadi route.

composer require laravel/folio

Contoh ide struktur halaman:

resources/views/pages/
├── index.blade.php
├── about.blade.php
├── pricing.blade.php
└── users/
    ├── index.blade.php
    └── [user].blade.php

Di sini, [user].blade.php menandakan route dinamis yang akan dibahas pada bagian berikutnya.

Parameter Route di Folio: Dinamis, Ringkas, tapi Tetap Perlu Disiplin

Salah satu hal terpenting dalam file-based routing adalah cara mendefinisikan parameter URL. Pada Folio, parameter route direpresentasikan melalui nama file atau folder khusus. Gagasan dasarnya: segmen URL dinamis ditulis sebagai placeholder di nama file.

Contoh:

resources/views/pages/users/[user].blade.php

File tersebut merepresentasikan URL seperti:

  • /users/1
  • /users/42
  • /users/john-doe

Parameter kemudian dapat digunakan di dalam halaman. Dalam praktik Laravel, parameter ini bisa dikaitkan dengan route model binding atau diakses sebagai nilai route mentah, tergantung cara Anda menggunakannya.

Contoh konsep penggunaan di Blade:

<?php
use App\Models\User;

$user = User::query()->where('id', request()->route('user'))->firstOrFail();
?>

<x-layouts.app :title="$user->name">
    <h1>{{ $user->name }}</h1>
    <p>Email: {{ $user->email }}</p>
</x-layouts.app>

Pada aplikasi nyata, Anda sebaiknya menjaga agar logika query tidak menumpuk di view. Jika halaman mulai melakukan banyak query, otorisasi, transformasi data, dan validasi parameter, itu tanda bahwa pendekatan ini mulai kehilangan kejelasan. Di titik itu, route klasik + controller atau class handler biasanya lebih sehat.

Kapan parameter Folio terasa nyaman?

  • Halaman detail sederhana, misalnya profil, artikel, atau halaman dokumentasi.
  • Parameter tunggal dengan alur baca yang jelas.
  • Ketika route model binding atau lookup data tidak kompleks.

Kapan mulai terasa berat?

  • Nested parameter seperti /teams/{team}/projects/{project}/deployments/{deployment}.
  • Butuh constraint parameter yang rumit.
  • Logika resolusi model bergantung pada konteks tenant, user, atau permission tertentu.
  • Route memiliki banyak variasi method atau perilaku yang berbeda.

Dengan kata lain, parameter route di Folio bagus untuk URL yang terbaca dan langsung, tetapi kurang nyaman jika desain URL dan resolusi datanya kompleks.

Middleware, Otorisasi, dan Layout: Bagaimana Folio Menjaga Struktur Aplikasi?

Salah satu kekhawatiran umum terhadap file-based routing adalah apakah ia tetap cocok untuk aplikasi yang butuh middleware, autentikasi, dan layout konsisten. Jawabannya: ya, tetapi Anda perlu tetap disiplin dalam pengorganisasian.

Middleware pada halaman Folio

Folio mendukung middleware agar halaman tertentu bisa dilindungi, misalnya hanya untuk user yang sudah login atau hanya admin. Secara konsep, Anda bisa menerapkan middleware pada kelompok halaman atau pada halaman tertentu, tergantung cara pendaftarannya di aplikasi.

Contoh skenario umum:

  • Semua halaman di area dashboard memakai middleware auth.
  • Halaman billing memakai auth dan middleware tambahan seperti pemeriksaan subscription.
  • Halaman admin memakai auth plus middleware otorisasi.

Struktur folder yang masuk akal misalnya:

resources/views/pages/
├── index.blade.php
├── docs/
│   ├── index.blade.php
│   └── installation.blade.php
└── dashboard/
    ├── index.blade.php
    ├── settings.blade.php
    └── billing.blade.php

Lalu area dashboard didaftarkan di bawah middleware auth. Pendekatan ini menjaga URL, file, dan kebijakan akses tetap relatif mudah ditelusuri.

Catatan: Jika kebutuhan middleware berbeda-beda di banyak halaman yang berdekatan secara URL, file-based routing bisa mulai terasa kurang eksplisit dibanding menuliskannya langsung di file route tradisional.

Layout dan integrasi dengan Blade

Karena Folio sangat dekat dengan Blade, integrasinya justru menjadi salah satu kekuatan utamanya. Anda bisa memakai layout Blade component yang sama seperti pada halaman Laravel biasa.

<x-layouts.app title="Dashboard">
    <h1 class="text-2xl font-semibold">Dashboard</h1>
    <p>Selamat datang kembali.</p>
</x-layouts.app>

Keuntungan praktisnya:

  • komponen Blade tetap bisa dipakai tanpa adaptasi besar,
  • layout global tetap konsisten,
  • halaman statis atau semi-dinamis bisa dibuat sangat cepat,
  • tim yang sudah nyaman dengan Blade tidak perlu belajar paradigma UI baru.

Tetapi perlu diingat, kemudahan ini juga bisa mengundang antipola: terlalu banyak logika aplikasi dipindah ke file Blade. Jika sebuah file halaman sudah berisi query database, pemeriksaan permission, formatting bisnis, dan cabang logika yang rumit, itu tanda untuk memindahkan sebagian tanggung jawab ke lapisan lain.

Perbandingan dengan Routing Klasik Laravel

Untuk mengevaluasi adopsi Folio, perbandingan paling adil adalah terhadap routing klasik Laravel, bukan terhadap framework lain. Keduanya punya kekuatan masing-masing.

1. Keterbacaan

Folio unggul ketika struktur aplikasi sangat page-oriented. Anda membuka folder, lalu langsung melihat peta URL. Untuk halaman seperti landing page, dokumentasi, profile, settings, atau halaman dashboard sederhana, ini terasa natural.

Routing klasik unggul ketika aplikasi memerlukan deklarasi yang eksplisit. Anda bisa melihat nama route, middleware, controller, constraint, prefix, dan group di satu tempat. Ini sangat membantu ketika URL bukan sekadar cerminan struktur folder.

Kesimpulan: Folio lebih terbaca untuk halaman sederhana; route klasik lebih terbaca untuk aplikasi dengan aturan routing kompleks.

2. Skalabilitas

Folio skalabel untuk banyak halaman yang pola kerjanya seragam. Namun ketika aplikasi tumbuh menjadi sistem dengan banyak modul bisnis, nested resources, banyak middleware, dan route non-HTML, pendekatan berbasis file bisa mulai kehilangan efisiensi mental.

Routing klasik lebih fleksibel untuk aplikasi besar karena abstraksinya jelas: route menuju controller/action, dan logika ditaruh di kelas yang memang dirancang untuk itu.

Kesimpulan: untuk skala aplikasi enterprise atau domain yang kompleks, route klasik biasanya lebih aman sebagai fondasi utama.

3. Testing

Dari sisi HTTP test, keduanya tetap bisa diuji dengan cara yang sangat mirip:

test('dashboard requires authentication', function () {
    $this->get('/dashboard')->assertRedirect('/login');
});

Masalahnya bukan pada kemampuan dites, melainkan pada struktur tanggung jawab. Jika halaman Folio memuat banyak logika langsung di Blade, testing unit menjadi kurang nyaman karena logika tidak terisolasi. Sebaliknya, pada route klasik, logika lebih mudah dipindahkan ke controller, action class, service, atau policy yang bisa diuji terpisah.

Kesimpulan: untuk HTTP test sederhana, sama-sama baik. Untuk maintainability test suite jangka panjang, route klasik cenderung lebih terstruktur jika domain logic kompleks.

4. Kesesuaian untuk tim besar

Pada tim kecil sampai menengah, Folio bisa meningkatkan produktivitas jika konvensinya jelas. File route menjadi lebih ringkas, onboarding halaman sederhana lebih cepat, dan developer bisa bergerak langsung dari URL ke file Blade.

Namun pada tim besar, ada beberapa potensi gesekan:

  • konvensi folder harus sangat disiplin,
  • batas antara presentasi dan logika bisa kabur,
  • review code lebih sulit jika logika tersebar di banyak file view,
  • pengelolaan perubahan route tidak selalu seterpusat file route tradisional.

Kesimpulan: Folio tetap bisa dipakai oleh tim besar, tetapi biasanya cocok hanya untuk area tertentu, bukan sebagai satu-satunya pendekatan.

Struktur Folder yang Masuk Akal untuk Proyek Nyata

Berikut contoh struktur yang cukup sehat jika Anda ingin mengadopsi Folio tanpa membuat aplikasi menjadi tidak konsisten:

resources/views/pages/
├── index.blade.php
├── about.blade.php
├── docs/
│   ├── index.blade.php
│   ├── installation.blade.php
│   └── deployment.blade.php
├── profile/
│   ├── index.blade.php
│   └── security.blade.php
└── users/
    ├── index.blade.php
    └── [user].blade.php

resources/views/components/layouts/
├── app.blade.php
└── marketing.blade.php

Pembagian semacam ini cocok bila:

  • docs adalah area publik dengan konten berbasis halaman,
  • profile adalah halaman user yang relatif sederhana,
  • users/[user] adalah halaman detail dengan query yang masih ringan.

Sementara route tradisional bisa tetap dipakai untuk:

  • API,
  • resource controller CRUD kompleks,
  • webhook,
  • route dengan banyak variasi method HTTP,
  • alur bisnis yang butuh controller/pipeline khusus.

Migrasi Kecil dari Route Tradisional ke Folio

Adopsi Folio tidak harus dilakukan sekaligus. Justru pendekatan paling aman adalah memindahkan area yang sederhana lebih dulu.

Sebelum: route tradisional

use Illuminate\Support\Facades\Route;

Route::view('/', 'welcome');
Route::view('/about', 'about');

Route::middleware('auth')->group(function () {
    Route::view('/dashboard', 'dashboard');
    Route::get('/profile', [ProfileController::class, 'show'])->name('profile.show');
});

Sesudah: sebagian dipindah ke Folio

Struktur halaman:

resources/views/pages/
├── index.blade.php
├── about.blade.php
└── dashboard/
    └── index.blade.php

Lalu biarkan /profile tetap di route klasik jika masih ditangani controller karena melibatkan update data, policy, form request, atau logika domain yang lebih berat.

Strategi migrasi yang aman:

  1. Pindahkan hanya route Route::view() atau halaman Blade sederhana.
  2. Biarkan endpoint yang memakai controller tetap pada router klasik.
  3. Tetapkan aturan tim: halaman Folio tidak boleh memuat query kompleks atau logika bisnis berat.
  4. Tambahkan HTTP test untuk memastikan URL lama tetap berfungsi.

Dengan cara ini, Anda memperoleh manfaat Folio tanpa memaksa semua bagian aplikasi mengikuti paradigma yang sama.

Trade-off, Kesalahan Umum, dan Tips Debugging

Trade-off utama

  • Lebih ringkas, tetapi bisa kurang eksplisit.
  • Mudah untuk halaman, tetapi tidak selalu ideal untuk alur bisnis kompleks.
  • Selaras dengan Blade, tetapi berisiko mencampur presentasi dan domain logic.

Kesalahan umum

  • Menjadikan Folio sebagai pengganti semua route, termasuk API dan webhook.
  • Memasukkan query database dan otorisasi kompleks langsung ke view.
  • Tidak menetapkan konvensi folder, penamaan, dan middleware per area.
  • Menganggap file-based routing otomatis lebih skalabel hanya karena lebih sedikit deklarasi route.

Tips debugging

  • Periksa apakah file berada di direktori Folio yang benar.
  • Pastikan nama file parameter sudah sesuai konvensi yang didukung.
  • Jika halaman tidak terlindungi, audit kembali pendaftaran middleware pada area terkait.
  • Jika parameter route tidak terbaca, inspeksi nilai dari request()->route().
  • Bila halaman mulai sulit diuji atau dipahami, pindahkan logika ke service, action, atau kembali ke controller.

Jadi, Kapan Folio Layak Dipakai?

Folio layak dipakai ketika aplikasi Anda memiliki cukup banyak halaman Blade yang berorientasi URL dan tampilan, dengan logika yang relatif ringan. Ia sangat cocok untuk halaman marketing, dokumentasi, dashboard sederhana, profile area, atau halaman internal yang tidak memerlukan orkestrasi controller yang berat.

Folio kurang ideal sebagai pendekatan tunggal jika aplikasi Anda sangat kaya domain logic, memiliki banyak alur CRUD kompleks, nested resource, route API, otorisasi berlapis, dan kebutuhan eksplisit yang tinggi untuk tim besar.

Dalam praktik terbaik, Folio sering paling efektif sebagai pelengkap routing klasik Laravel, bukan pengganti total. Gunakan Folio untuk halaman yang memang cocok dengan model file-based routing, dan tetap gunakan route tradisional untuk area yang membutuhkan kontrol arsitektural lebih jelas.

Jika Anda sedang mengevaluasi adopsi, mulailah dari area kecil yang risikonya rendah: halaman statis, dokumentasi internal, atau dashboard ringan. Dari sana, ukur apakah struktur kode menjadi lebih mudah dipahami oleh tim, bukan hanya lebih singkat ditulis. Pada akhirnya, keputusan yang tepat bukan soal mengikuti tren routing, melainkan memilih abstraksi yang paling jelas untuk beban kerja aplikasi Anda.