Batasan Framework Buatan Sendiri

Kita baru saja menyelesaikan sesuatu yang tidak sepele: router dengan parameter dinamis, middleware pipeline, dependency container, template engine, exception handler, dan jaring pengujian — semuanya ditulis tangan. Namun justru karena kita membangunnya sendiri, kita berada di posisi terbaik untuk menilainya secara jujur. Chapter penutup section ini bukan rayuan gengsi, melainkan refleksi terbuka: apa yang tidak dimiliki framework mini kita, berapa harga pemeliharaannya, kapan membangun sendiri tetap masuk akal, dan bagaimana jalan bermigrasi ke framework matang tanpa membuang semua yang telah kita pelajari.

Apa yang Tidak Dimiliki Framework Mini #

Cara paling jernih melihatnya adalah menghitung. Aplikasi nyata menuntut fitur yang terus bertambah, sementara framework mini hanya punya yang kita rakit sendiri:

<?php

// Kebutuhan aplikasi yang terus bertambah seiring waktu
$kebutuhanProyek = ["auth", "queue", "email", "full-text search"];

// Yang dimiliki framework mini setelah seluruh section ini selesai
$fiturFrameworkMini = ["router", "container", "middleware", "template", "exception handler"];

$harusDibuatSendiri = array_diff($kebutuhanProyek, $fiturFrameworkMini);

echo "Fitur yang harus ditulis dari nol: ", implode(", ", $harusDibuatSendiri), "\n";
echo "Jumlah: ", count($harusDibuatSendiri), " fitur\n";

Output yang Dihasilkan:

Fitur yang harus ditulis dari nol: auth, queue, email, full-text search
Jumlah: 4 fitur

array_diff() di atas adalah analogi yang tepat: dari empat kebutuhan, tidak satu pun tersedia. Auth harus ditulis lengkap dengan hashing, session, reset password, dan rate limiting. Queue butuh worker, retry, dan penanganan kegagalan. Email butuh abstraksi SMTP plus template. Setiap barisnya adalah kode yang harus kita tulis, uji, dan amankan sendiri — sementara framework matang menyediakannya sebagai paket yang sudah melalui bertahun-tahun pemakaian. Celahnya bahkan lebih luas dari daftar fitur:

Biaya Pemeliharaan: Anda Menjadi Maintainer #

Memakai framework berarti menyewa tim pemelihara; membangun sendiri berarti menjadi tim itu. Biayanya muncul paling nyata saat PHP merilis versi baru. Sebagai contoh nyata, PHP 8.4 mendeprekasi parameter implicitly nullable — penulisan function f(string $x = null) yang dulu diterima kini memicu Deprecated dan ditargetkan dihapus di PHP 9. Kode yang ditulis sebelum aturan ini ada harus diperiksa dan diperbaiki satu per satu, dan bentuk amannya eksplisit:

<?php

function formatHarga(?float $harga = null): string
{
    return "Rp" . number_format($harga ?? 0, 0, ",", ".");
}

echo formatHarga(1500000), "\n";
echo formatHarga(), "\n";

Output yang Dihasilkan:

Rp1.500.000
Rp0

Perbaikannya memang kecil — tambahkan tanda tanya pada tipe — tetapi yang perlu dilihat adalah polanya: setiap perubahan bahasa, setiap perbaikan bug keamanan, setiap fitur baru yang dibutuhkan produk, semuanya menunggu kita. Framework mini tidak punya rilis berkala, tidak ada changelog yang ditulis orang lain, dan tidak ada komunitas yang menambal celah di akhir pekan. Pada framework matang, PHP 8.4 keluar dan ekosistemnya menyesuaikan dalam hitungan minggu; pada framework kita, penyesuaian itu hanya terjadi jika kita meluangkan waktu.

Kapan Membangun Sendiri Tetap Bernilai #

Refleksi jujur bukan berarti menyesali. Membangun framework mini punya dua nilai yang tidak bisa dibeli dengan composer require. Pertama, dan terbesar: pembelajaran. Anda sekarang tahu bahwa routing adalah kompilasi pola ke regex, bahwa DI container hanyalah map dari string ke factory, bahwa middleware adalah composition of callables, dan bahwa exception handler hanyalah satu try/catch di tempat yang tepat. Sihir Laravel dan Symfony hilang, digantikan pemahaman — dan pemahaman itu membuat kita jauh lebih efektif saat memakai framework apa pun.

Kedua: kesederhanaan untuk kebutuhan kecil. Untuk internal tool dengan pengguna sedikit, dependency minim, dan kebutuhan stabil, framework 500 baris yang sepenuhnya dipahami kadang lebih sehat daripada framework penuh dengan ratusan dependensi. Tidak ada proses upgrade besar yang mengikutinya, tidak ada dependensi yang tiba-tiba ditinggalkan pengembangnya, dan setiap baris bisa dijelaskan. Kuncinya adalah kejujuran soal lingkup: framework mini layak untuk alat internal kecil, bukan untuk produk publik yang tumbuh.

Sinyal Sudah Saatnya Beralih #

Momen beralih biasanya tidak datang sebagai keputusan besar, melainkan kumpulan sinyal kecil yang menumpuk:

Satu sinyal saja belum tentu berarti beralih; tiga atau lebih yang muncul bersamaan hampir pasti berarti waktunya tiba.

Jalur Migrasi: Konsep Anda Sudah Transfer #

Kabar baiknya: bermigrasi tidak berarti membuang pengetahuan. Konsep yang kita bangun tangan sendiri adalah konsep yang sama yang berdiri di balik framework matang — hanya namanya yang berbeda:

Saat membaca dokumentasi Laravel tentang service container, kita tidak sedang belajar hal baru — kita sedang mengenali versi yang lebih dewasa dari sesuatu yang pernah kita tulis. Migrasi kode pun mengikuti pola yang sama: pindahkan satu route pada satu waktu, ganti panggilan matchRoute() dengan route beneran, biarkan pengujian golden master dari chapter framework testing memverifikasi bahwa respons tidak berubah. Strategi ini dikenal sebagai strangler pattern — framework baru perlahan “mencekik” yang lama dari luar, tanpa migrasi besar-besaran yang berisiko.

Waspada Sindrom NIH #

Ada satu jebakan psikologis yang menemani keberhasilan membangun sendiri: Not Invented Here (NIH) — keyakinan bahwa kode buatan orang lain tidak akan pernah sebaik kode buatan kita sendiri. Gejalanya mudah dikenali: menolak paket yang teruji lalu menulis versi sendiri, membandingkan keunggulan versi sendiri yang belum pernah dipakai siapa pun, atau merasa membaca kode orang lain lebih berat daripada menulis ulang. Pertanyaan pembandingnya sederhana: apakah infrastruktur ini kompetensi inti produk kita? Router untuk aplikasi jualan kopi bukan kompetensi inti; mesin rekomendasi kopi mungkin iya. Nilai engineering justru terletak pada kemampuan memilih pertarungan yang layak dikerjakan sendiri.

Ringkasan #

Framework mini kita berhasil sebagai proyek belajar dan layak untuk alat internal kecil, tetapi jujur gagal sebagai fondasi produk publik: tanpa patch keamanan, dokumentasi, komunitas, dan battle-testing — dengan kita sendiri sebagai maintainer tunggal yang menanggung setiap perubahan PHP. Sinyal beralih muncul saat tim tumbuh dan kebutuhan produk melampaui infrastruktur kita, dan jalur migrasinya mulus karena setiap komponen mini memiliki padanan langsung di Laravel dan Symfony. Pengetahuan yang paling bernilai dari section ini bukan frameworknya, melainkan peleburan “sihir” framework menjadi pola yang bisa dibaca. Dengan bekal itu, section berikutnya mengajak kita berkenalan dengan framework nyata — dimulai dari memahami PHP frameworks .

Referensi #

• PHP Supported Versions
• Migrating from PHP 8.3 to 8.4
• Laravel Documentation
• Symfony Documentation