Memilih Framework PHP

Framework adalah dependensi terbesar yang akan diambil sebuah proyek PHP: framework menentukan struktur kode, memengaruhi siapa yang bisa direkrut, dan menetapkan irama pemeliharaan bertahun-tahun ke depan. Sayangnya, diskusi memilih framework sering berhenti menjadi perang selera di media sosial. Chapter penutup section ini mengembalikan keputusan tersebut ke ranah teknis: kita susun faktor-faktor yang benar-benar memengaruhi hasil, petakan empat kandidat dari chapter-chapter sebelumnya, akui legitimasi jalan tanpa framework, hitung biaya berpindah, lalu tuangkan semuanya menjadi rubrik rekomendasi yang bisa dihitung dengan kode.

Keputusan Teknis, Bukan Loyalitas #

Pertanyaan yang benar bukan “framework mana yang terbaik?” melainkan “framework mana yang paling cocok dengan tim, proyek, dan horizon pemeliharaan kita?”. Jawabannya berbeda untuk startup tiga orang yang mengejar validasi produk, instansi yang memelihara sistem selama satu dekade, dan tim platform yang membangun layanan internal. Ketiganya bisa memilih hal berbeda tanpa ada yang salah.

Faktor-Faktor Penentu #

Satu baris pada tabel tersebut perlu diluruskan dengan data, bukan kesan: performa. Ketiga framework besar berjalan pada PHP dengan model request-per-proses yang sama, dan pada aplikasi nyata hampir selalu query database, I/O berkas, dan panggilan layanan eksternal yang mendominasi waktu respons — bukan framework. Benchmark yang menunjukkan framework A 20% lebih cepat dari framework B pada hello world tidak berarti apa-apa bila halaman sesungguhnya menjalankan dua puluh query yang tidak diindeks. Ukur profil aplikasi dulu, baru menyalahkan framework.

Peta Empat Kandidat #

Opsi Tanpa Framework yang Sah #

Sepanjang section Framework Development kita membuktikan sendiri bahwa kerangka dasar aplikasi web — router, middleware, container, template — bisa dibangun dalam ratusan baris PHP. Opsi tanpa framework bukan berarti menulis dari nol setiap proyek; opsi tersebut berarti menyusun kerangka kerja sendiri: memilih komponen Composer satu per satu dan menulis lem perekat yang tepat untuk kebutuhan kita.

Jalan ini sah untuk tiga situasi. Pertama, alat kecil — CLI tool, skrip cron, satu endpoint webhook — yang tidak mendapat apa pun dari framework penuh. Kedua, proyek dengan batasan keras: lingkungan eksekusi yang aneh, kebutuhan jejak memori minimum, atau kebijakan audit yang mensyaratkan setiap baris kode bisa dijelaskan. Ketiga, pembelajaran: membangun framework mini adalah cara tercepat memahami apa yang framework lakukan untuk kita.

Harganya juga jujur harus disebut. Tanpa framework, kita menjadi maintainer infrastruktur sendiri: patch keamanan untuk kode perekat kita tidak akan datang dari siapa pun, kecuali kita yang menulis. Untuk aplikasi web yang melayani pengguna nyata dengan data nyata, pertimbangkan opsi ini sebagai keputusan sadar yang dibebani komitmen, bukan sebagai jalan pintas.

Biaya Berpindah Framework #

Framework jarang dipilih selamanya, dan pemahaman tentang biaya berpindah membuat kita memilih dengan lebih tenang. Perpindahan menagih tiga tagihan. Tagihan pertama adalah kode: routing, controller, validasi, dan konfigurasi harus ditulis ulang pada idiom framework baru — meskipun SQL dan logika domain bisa ikut pindah hampir utuh. Tagihan kedua adalah manusia: tim harus belajar framework baru pada jam-jam yang seharusnya dipakai membangun fitur. Tagihan ketiga adalah kepercayaan: regresi pada aplikasi yang sudah berjalan selama migrasi membuat pengguna dan pemangku kepentingan membayar kesalahan yang sebenarnya bukan milik mereka.

Mitigasi terbaik dikerjakan sejak hari pertama, bukan saat migrasi: jaga lapisan domain tetap framework-agnostic. Logika bisnis yang hidup di service murni PHP tanpa import framework — pola Layered Architecture dengan controller sebagai lapisan tipis penerjemah HTTP — bisa dibawa pindah hampir tanpa sentuhan. Semakin tebal logika yang menempel pada framework, semakin mahal tiket pindahnya.

Framework sebagai Risiko Dependensi #

Framework adalah dependensi dengan siklus rilis dan prioritas sendiri. Versi mayor bisa mengubah API yang kita pakai; paket ekosistem favorit bisa berhenti dirawat pengelolanya; dan keputusan desain hulu bisa berlawanan dengan kebutuhan kita. Risiko ini bukan alasan menghindari framework — melainkan alasan mengelolanya seperti dependensi lain: disadari, dibatasi, diaudit.

Dua praktik membatasi dampaknya. Pertama, bertumpu pada standar terbuka di titik sentuh penting: middleware PSR-15, pesan HTTP PSR-7, dan interface logger PSR-3 membuat bagian aplikasi bisa bertahan melewati penggantian framework — pelajaran yang kita lihat langsung pada Slim yang bisa menukar implementasi PSR-7 tanpa mengubah kode. Kedua, menjalankan audit dependensi rutin sebagaimana dibahas di Dependency Auditing : mengetahui paket yang terbengkalai lebih awal memberi kita waktu mencari pengganti sebelum pakai itu menjadi lubang keamanan.

Rubrik Rekomendasi Sederhana #

Diskusi faktor menjadi lebih terkendali bila dituangkan ke angka. Rubrik berikut memberi skor pada tiap kandidat: setiap faktor diberi bobot kepentingan, setiap kandidat diberi nilai kecocokan, dan hasil akhirnya adalah perkalian keduanya dijumlahkan. Seluruh input bersifat tetap sehingga hasilnya bisa dijalankan dan diperiksa ulang:

<?php
/**
 * Rubrik sederhana pemilihan framework.
 * - hitungSkor(): jumlah bobot faktor dikali kecocokan kandidat.
 * - rekomendasi(): mengurutkan kandidat dari skor tertinggi.
 * Skala: bobot faktor 1-3, kecocokan kandidat 0-2.
 */
function hitungSkor(array $bobotFaktor, array $kecocokanKandidat): int
{
    $skor = 0;
    foreach ($kecocokanKandidat as $faktor => $kecocokan) {
        $skor += ($bobotFaktor[$faktor] ?? 0) * $kecocokan;
    }

    return $skor;
}

function rekomendasi(array $bobotFaktor, array $semuaKandidat): array
{
    $peringkat = [];
    foreach ($semuaKandidat as $kandidat => $kecocokan) {
        $peringkat[$kandidat] = hitungSkor($bobotFaktor, $kecocokan);
    }
    arsort($peringkat);

    return $peringkat;
}

$kandidat = [
    'Laravel' => ['kecepatan_mulai' => 2, 'fitur_lengkap' => 2, 'kontrol_penuh' => 0, 'jejak_kode' => 1],
    'Symfony' => ['kecepatan_mulai' => 0, 'fitur_lengkap' => 2, 'kontrol_penuh' => 2, 'jejak_kode' => 1],
    'Slim' => ['kecepatan_mulai' => 2, 'fitur_lengkap' => 0, 'kontrol_penuh' => 2, 'jejak_kode' => 2],
    'Tanpa framework' => ['kecepatan_mulai' => 0, 'fitur_lengkap' => 0, 'kontrol_penuh' => 2, 'jejak_kode' => 2],
];

$skenario = [
    'Situs perusahaan (tim kecil, fitur lengkap)' => ['kecepatan_mulai' => 3, 'fitur_lengkap' => 3, 'kontrol_penuh' => 1, 'jejak_kode' => 1],
    'API internal (tim senior, kendali penuh)' => ['kecepatan_mulai' => 2, 'fitur_lengkap' => 0, 'kontrol_penuh' => 3, 'jejak_kode' => 3],
];

foreach ($skenario as $nama => $bobot) {
    echo "Skenario: $nama\n";
    $peringkat = rekomendasi($bobot, $kandidat);
    foreach ($peringkat as $pendekatan => $skor) {
        echo "  " . str_pad($pendekatan, 16) . str_pad((string) $skor, 4, ' ', STR_PAD_LEFT) . "\n";
    }
    echo "  => Rekomendasi: " . array_key_first($peringkat) . "\n";
}

Output yang Dihasilkan:

Skenario: Situs perusahaan (tim kecil, fitur lengkap)
  Laravel           13
  Slim              10
  Symfony            9
  Tanpa framework    4
  => Rekomendasi: Laravel
Skenario: API internal (tim senior, kendali penuh)
  Slim              16
  Tanpa framework   12
  Symfony            9
  Laravel            7
  => Rekomendasi: Slim

Fungsi hitungSkor() menjalankan inti rubrik: setiap faktor dikalikan bobotnya lalu dijumlahkan, sehingga faktor berbobot 3 berpengaruh tiga kali lipat dibanding faktor berbobot 1. Fungsi rekomendasi() menghitung skor seluruh kandidat lalu mengurutkannya dengan arsort(). Array $kandidat menilai kecocokan tetap per framework — Laravel kuat pada kecepatan mulai dan kelengkapan fitur, Slim pada kendali dan jejak kode, dan seterusnya. Dua skenario memperlihatkan sensitivitasnya: bobot “fitur lengkap tinggi” mengangkat Laravel untuk situs perusahaan, sedangkan bobot “kendali penuh dan jejak kode” memilih Slim untuk API internal tim senior.

Rubrik seperti ini bukan pengganti diskusi — angka pada tabel kecocokan adalah pendapat yang disamarkan. Kekuatannya justru di sana: rubrik memaksa setiap asumsi ditulis terbuka, bisa dibantah satu per satu, dan perubahan bobot langsung terlihat dampaknya. Ubah nilai kecocokan sesuai penilaian tim Anda sendiri; yang penting tetap adalah keputusan yang bisa dilacak asal-usulnya.

Ringkasan #

Memilih framework adalah latihan kejujuran konteks: tim seperti apa yang kita punya, proyek seperti apa yang kita bangun, dan berapa lama keduanya akan hidup. Laravel menukar keterbacaan dengan kecepatan, Symfony menukar keringkasan dengan eksplisit, Slim menukar kelengkapan dengan transparansi, dan jalan tanpa framework menukar kenyamanan dengan kendali. Dengan framework di tangan, pertanyaan kita berikutnya naik satu tingkat: bentuk apa yang harus diberikan pada aplikasi secara keseluruhan? Section Modern Web Architecture membuka diskusi itu, dimulai dari aplikasi yang dirender di server.

Referensi #

• PHP The Right Way
• Laravel Documentation
• Symfony Documentation
• Composer: Versions and Constraints