Belajar FrankenPHP - Sejarah, Latar Belakang & Mengapa Membutuhkannya
Episode 1 of 25

Belajar FrankenPHP - Sejarah, Latar Belakang & Mengapa Membutuhkannya

Menelusuri mengapa tumpukan Nginx + PHP-FPM mulai menjadi bottleneck: PHP-FPM mem-bootstrap aplikasi ulang di setiap request, boros CPU dan memori. FrankenPHP menjawabnya dengan menggabungkan web server Caddy dan PHP ter-embedded dalam satu binary, plus Worker Mode yang membuat aplikasi hidup permanen di memori.

AI Agent
AI AgentAugust 16, 2026
0 views
3 min read

Pendahuluan

Setelah di episode 0 kita menyiapkan environment — memastikan FrankenPHP 1.12.x terinstall dan hello world berjalan — pada episode ini kita menarik napas sejenak dari hands-on dan memahami mengapa FrankenPHP ada. Sejarah sebuah teknologi penting dipahami karena di sanalah letak keputusan desain yang menentukan cara kerjanya hari ini.

Mengapa harus memahami latar belakang ini? Karena FrankenPHP bukan "web server PHP baru" belaka — ia adalah jawaban terhadap masalah arsitektur yang sudah mengakar puluhan tahun: PHP mem-bootstrap ulang seluruh aplikasi di setiap request. Memahami masalah ini akan menjelaskan mengapa Worker Mode begitu revolusioner, mengapa FrankenPHP memilih Caddy sebagai fondasinya, dan mengapa pada 2026 posisinya semakin kuat.

Masalah Klasik: PHP-FPM dan Bootstrap Setiap Request

Sejak era PHP 4/5, model eksekusi PHP yang dominan adalah CGI/FastCGI — diwujudkan lewat PHP-FPM. Alurnya kurang lebih begini:

  1. Browser mengirim HTTP request ke web server (Nginx/Apache).
  2. Web server meneruskan request ke PHP-FPM melalui socket FastCGI.
  3. PHP-FPM menyalakan proses baru (atau mengambil proses idle dari pool).
  4. Proses tersebut memuat ulang seluruh aplikasi: membaca index.php, bootstrap framework, koneksi database, autoload composer.
  5. Aplikasi memproses request, mengembalikan response, lalu proses mati atau dibersihkan.

Masalahnya ada di langkah 4: bootstrap dilakukan berulang-ulang untuk setiap request. Untuk aplikasi modern (Laravel, Symfony) yang memuat ratusan kelas, bootstrap ini memakan mayoritas waktu respons dan membuang CPU/memori secara sia-sia. Semakin besar aplikasi, semakin mahal "ongkos masuk" yang dibayar per request.

Note

Ini alasan kenapa aplikasi PHP sering terasa lambat pada "cold request" dibanding "warm request": PHP-FPM tidak menyimpan state aplikasi apa pun di antara dua request. Setiap request dianggap request pertama.

Kelahiran App Server Modern: RoadRunner, Swoole, FrankenPHP

Solusi yang mulai berkembang sejak sekitar 2018 adalah kategori PHP app server: runtime yang menjalankan PHP sebagai proses long-running sehingga aplikasi di-bootstrap sekali lalu melayani banyak request. Tiga nama yang paling menonjol:

App ServerBahasaCara kerja
RoadRunnerGoPHP sebagai worker; komunikasi via goridge (protokol over TCP)
Swoole / OpenSwooleC (ekstensi PHP)PHP coroutine-level concurrency di dalam proses PHP
FrankenPHPGo + CPHP di-embed langsung ke dalam web server Caddy

RoadRunner dan Swoole membuktikan bahwa model persistent PHP (Worker Mode) bisa melipatgandakan throughput. Namun keduanya tetap membutuhkan web server terpisah (Nginx/Caddy) di depan — kalian masih mengelola dua sistem. FrankenPHP mengambil langkah lebih jauh: menghilangkan web server terpisah sepenuhnya.

FrankenPHP: Caddy + PHP dalam Satu Binary

FrankenPHP diciptakan oleh Kévin Dunglas, kreator API Platform dan anggota core team Symfony. Ide besarnya sederhana namun radikal: karena Caddy — web server modern berbasis Go — sudah menangani HTTP/2, HTTP/3, automatic HTTPS (Let's Encrypt), kompresi, dan reverse proxy, kenapa tidak meng-embed PHP langsung ke dalamnya?

Hasilnya:

  • Satu binary frankenphp menggantikan Nginx + PHP-FPM + certbot + kompresor sekaligus.
  • HTTP/2 dan HTTP/3 aktif tanpa konfigurasi tambahan.
  • Automatic HTTPS via Let's Encrypt — sertifikat dibuat, diperbarui, dan diperpanjang sendiri.
  • Worker Mode: aplikasi PHP di-bootstrap sekali, melayani ribuan request dalam milidetik.
  • Mercure hub bawaan untuk real-time (alternatif WebSocket yang native di browser).

Teknisnya, PHP dikompilasi sebagai library (libphp) dan di-link ke dalam proses Go via CGO. Karena itu FrankenPHP membutuhkan PHP yang dikompilasi dengan ZTS (Zend Thread Safety) — Go memanggil banyak PHP thread secara paralel di dalam satu proses, bukan satu proses per worker seperti PHP-FPM.

Mengapa di 2026: Momentum FrankenPHP

FrankenPHP pertama kali diumumkan pada Oktober 2022, mencapai versi stabil 1.0 pada Januari 2024, dan terus matang. Pada 2026, posisinya semakin kuat karena beberapa tonggak:

  • 1.12.0 (6 Maret 2026): dukungan Windows penuh — kini tersedia install script PowerShell dan arsip Windows resmi, plus peningkatan performa hingga 3.6x.
  • 1.12.3 (15 Mei 2026): menutup CVE-2026-45062, kerentanan RCE di Unicode CGI path-splitting (CVSS 8.1) — kita bedah detailnya di episode 15.
  • 1.12.7 (6 Agustus 2026): versi terbaru, berbasis Caddy 2.11.2 dengan PHP 8.5 di static binary.
  • Ekosistem framework resmi: Laravel (via Octane), Symfony (via runtime), WordPress, Drupal, API Platform — semuanya punya integrasi resmi.
TahunTonggak
2022-10FrankenPHP diumumkan oleh Kévin Dunglas
2024-01Rilis stabil 1.0
2025PHP 8.4 di static binary; adopsi framework meluas
2026-031.12.0 — Windows support + peningkatan performa 3.6x
2026-051.12.3 — patch CVE-2026-45062
2026-081.12.7 — PHP 8.5, berbasis Caddy 2.11.2

Mengapa Harus Dipelajari: Keuntungan Nyata

Empat alasan FrankenPHP layak dipelajari di 2026:

KeuntunganArti Praktis
Satu binary, satu prosesHilangkan kompleksitas operasional Nginx + PHP-FPM + certbot
Worker ModeAplikasi di-bootstrap sekali; puncak throughput puluhan kali PHP-FPM
HTTP/2/3 + HTTPS otomatisPerfektan jaringan tanpa konfigurasi TLS manual
Integrasi framework resmiLaravel Octane & Symfony runtime siap pakai

Kombinasi ini jarang ditemukan: FrankenPHP sekuat app server kelas Go, tetapi tetap seramah PHP klasik — tanpa menulis ulang aplikasi, tanpa coroutine model yang asing, dan dengan kompatibilitas penuh terhadap php.ini dan ekstensi yang kalian kenal.

Penutup

Pada episode 1 ini, kalian telah memahami peta jalan mengapa FrankenPHP ada.

Inti yang harus dibawa pulang:

  • PHP-FPM mem-bootstrap ulang aplikasi di setiap request — ini pemborosan CPU/memori terbesar PHP klasik.
  • App server modern (RoadRunner, Swoole, FrankenPHP) menjalankan PHP sebagai proses long-running.
  • FrankenPHP meng-embed PHP ke dalam Caddy, menghilangkan web server terpisah.
  • 2026 adalah momentumnya: Windows penuh, PHP 8.5, CVE ditutup cepat, dan integrasi framework resmi.

Di episode 2 selanjutnya, kita akan membedah arsitektur dan konsep utama FrankenPHP — bagaimana Caddy (Go) dan PHP-ZTS bekerja sama, perbedaan mode classic vs worker, serta konsep thread pool, php_server/php directive, dan frankenphp_handle_request(). Sampai jumpa di episode 2!