Memahami PHP Frameworks

Selama satu section penuh kita membangun framework mini dengan tangan sendiri, dan hasilnya bisa jalan: routing, middleware, container, template, sampai penanganannya teruji. Sekarang saatnya melihat ke luar. Framework PHP nyata menopang sebagian besar aplikasi web dunia, dari toko kecil hingga sistem berskala jutaan pengguna. Pada chapter pembuka section ini kita memahami mengapa framework ada, apa yang mereka standarisasi, bagaimana peta lanskapnya, dan mengapa perjalanan kita di framework development membuat kita justru lebih siap memakainya.

Mengapa Framework Ada #

Menulis aplikasi web tanpa framework berarti menulis ulang hal yang sama berulang kali: membaca request, mencocokkan URL, memvalidasi input, mengelola session, menyusun respons. Kode-kode ini tidak membedakan produk kita sama sekali — toko buku dan aplikasi klinik menulis router yang hampir identik. Framework memutus pengulangan itu dengan menyediakan infrastruktur umum sebagai pustaka yang teruji, sehingga waktu tim terfokus pada logika yang benar-benar khas produk: katalog, keranjang, rekam medis.

Alasan kedua lebih halus namun lebih besar dampaknya untuk tim. Ketika semua proyek memakai konvensi yang sama — request masuk lewat controller, dependensi lewat container, error lewat handler — maka rekan kerja baru bisa langsung produktif tanpa membaca seluruh codebase. Standarisasi memindahkan pengetahuan dari kepala perorangan ke struktur yang bisa dipelajari siapa pun. Kita merasakannya sendiri dalam skala kecil: framework mini kita konsisten karena satu tangan yang menulisnya; framework nyata konsisten karena konvensinya dipaksa oleh desain.

Apa yang Distandarisasi Framework #

Melampaui struktur folder, framework matang menyediakan jaminan-jaminan yang sulit kita raih sendiri. Sebagian besar sudah pernah kita bangun versi mininya:

• Alur request–response: dari URL masuk sampai respons keluar, lewat routing, middleware, controller — lengkap dengan exception handler sebagai garis pertahanan terakhir.
• Keamanan bawaan: proteksi CSRF, escaping output template, query builder yang aman dari SQL injection, dan password hashing yang terkonfigurasi benar secara default.
• Dependency injection: container yang menyusun objek secara otomatis, sehingga komponen saling terhubung tanpa inisialisasi manual.
• Alat kerja: migrasi database, pengujian terintegrasi, logging, dan perintah CLI yang menyertai siklus hidup aplikasi.

Setiap butir di atas adalah topik yang pernah kita bangun tangan sendiri di section framework development — perbedaannya hanya skala, kedewasaan, dan jumlah mata yang telah mengawasinya.

Peta Lanskap Framework PHP #

Lima nama mendominasi percakapan framework PHP. Tidak ada yang “terbaik” secara mutlak — masing-masing memilih titik berbeda pada garis antara kelengkapan dan kesederhanaan:

Laravel dan Symfony adalah dua raksasa yang menyerap mayoritas proyek baru. Slim berdiri di ujung berlawanan: framework mikro yang hanya memberi routing dan middleware, dan membiarkan kita memilih sisanya. Yii dan Laminas mengisi ceruk masing-masing — Yii dengan produktivitas CRUD bawaan, Laminas dengan arsitektur modular untuk sistem korporat yang kompleks.

Batteries-Included vs Mikro #

Istilah batteries-included berarti framework datang dengan hampir semua kebutuhan di dalam kotak: ORM, validasi, auth, queue, email, task scheduling. Framework mikro menyertakan seminimal mungkin dan mempercayakan sisanya pada pilihan kita. Skala keduanya paling mudah dilihat dengan menghitung:

<?php

$framework = [
    "Laravel" => ["router", "container", "middleware", "orm", "validation", "auth", "queue"],
    "Slim" => ["router", "middleware", "di"],
    "Mini kita" => ["router", "container", "middleware", "template"],
];

foreach ($framework as $nama => $fitur) {
    printf("%-10s: %d fitur inti — %s\n", $nama, count($fitur), implode(", ", $fitur));
}

Output yang Dihasilkan:

Laravel   : 7 fitur inti — router, container, middleware, orm, validation, auth, queue
Slim      : 3 fitur inti — router, middleware, di
Mini kita : 4 fitur inti — router, container, middleware, template

Framework mini kita ternyata berdiri lebih dekat ke Slim daripada ke Laravel: keduanya hanya menyediakan inti, bukan seluruh isi kotak. Pertukarannya jelas — batteries-included mempercepat awal proyek karena keputusan sudah diambilkan, tetapi membawa permukaan yang harus dipelajari; framework mikro memulai ringan, tetapi setiap kebutuhan baru berarti memilih dan merakit sendiri. Tim kecil membangun API sederhana sering bahagia dengan mikro; produk yang tumbuh ke banyak fitur biasanya lebih terlayani oleh yang lengkap.

Belajar Satu Framework Berarti Belajar Konsepnya #

Keuntungan terbesar dari perjalanan kita membangun framework mini bersifat menyeberang: konsep yang sama hidup di semua framework, hanya namanya yang berbeda. Tidak ada “routing ala Laravel” yang fundamentalnya berbeda dari “routing ala Symfony” — keduanya mencocokkan pola URL dan meng-inject parameter ke action, persis yang kita tulis di chapter routing parameters :

Konsekuensinya praktis: meluangkan waktu memahami satu framework secara dalam lebih bernilai daripada mengenal lima framework secara dangkal. Ketika konsep middleware, container, dan request lifecycle sudah kuat, pindah dari Laravel ke Symfony menjadi urusan mempelajari sintaks dan konvensi — bukan membangun ulang cara berpikir.

Komponen di Bawah Kerangka Framework #

Rahasia yang jarang disadari pemula: framework besar pun tidak menulis segalanya sendiri. Laravel dibangun di atas puluhan komponen Symfony — http-foundation untuk request–response, routing untuk pencocokan route, console untuk perintah Artisan. Komponen-komponen ini adalah pustaka mandiri yang bisa kita pakai langsung, tanpa framework utuhnya, lewat satu perintah Composer:

{
    "require": {
        "symfony/routing": "^7.3",
        "symfony/http-foundation": "^7.3"
    }
}

Setelah terpasang, komponen routing Symfony dipakai layaknya pustaka biasa — dan perhatikan betapa akrabnya bentuknya:

<?php

// composer require symfony/routing
use Symfony\Component\Routing\Route;
use Symfony\Component\Routing\RouteCollection;

$routes = new RouteCollection();
$routes->add("produk_show", new Route(
    "/produk/{id}",
    ["_controller" => "ProdukController::show"],
    ["id" => "\d+"]
));

Pola /produk/{id} dengan requirements \d+ adalah persis pola plus constraint yang kita kompilasi sendiri menjadi regex di chapter routing parameters. Composer-lah yang menjahit ekosistem ini: setiap pustaka dipublikasikan sebagai paket, dinyatakan di composer.json, dan bisa dirakit ulang sesuai kebutuhan. Memahami lapisan komponen membuat kita fleksibel — tidak harus membeli keseluruhan framework hanya untuk memakai satu bagian unggulannya.

Sekilas Faktor Pemilihan #

Bagaimana memilih di antara semua ini? Pertanyaan lengkapnya akan kita uraikan pada chapter memilih framework PHP di akhir section, tetapi faktor-faktornya bisa dikenali sejak sekarang: kebutuhan proyek (API kecil vs aplikasi penuh fitur), keahlian tim saat ini, ketersediaan paket untuk kebutuhan domain, mutu dokumentasi, dan kesehatan komunitas di sekitarnya. Perhatikan bahwa tidak satu pun faktor itu teknis semata — framework dipilih oleh tim dan untuk tim, bukan oleh benchmark tercepat.

Ringkasan #

Framework PHP ada karena infrastruktur web itu generik dan layak ditulis sekali dengan baik: routing, DI, keamanan default, dan tooling yang terstandarisasi lintas proyek dan lintas tim. Lanskapnya membentang dari batteries-included seperti Laravel dan Symfony hingga mikro seperti Slim, dengan Yii dan Laminas di ceruk masing-masing. Konsep yang kita bangun sendiri di framework mini adalah konsep yang sama yang menopang semuanya, dan komponen-komponen di bawah kerangka besar tersedia bagi siapa pun lewat Composer. Dengan peta ini di tangan, kita siap memasuki wilayah framework terpopuler saat ini — mulai dari Laravel fundamentals .

Referensi #

• Laravel Documentation
• Symfony Documentation
• Slim Framework Documentation
• Composer Documentation