Kebangkitan PHP Hibrida: Menggabungkan PHP dengan Go dan Rust

• Belakangan ini, pendekatan hibrida yang mengintegrasikan Go dan Rust sebagai bahasa ekstensi di dalam arsitektur monolitik PHP semakin mendapat perhatian
• Sebelumnya, kombinasi microservice Go dan monolitik PHP 8.3 memungkinkan tercapainya keseimbangan antara produktivitas dan kinerja tinggi
• Sesuai hukum Pareto (80% trafik terkonsentrasi pada 20% API), optimalisasi endpoint hotspot menjadi hal yang penting, dan di masa lalu hal ini ditangani dengan caching serta pemisahan layanan Go, tetapi kompleksitasnya meningkat
• Perkembangan terbaru dalam ekosistem PHP menghadirkan teknik seperti FFI, ekstensi Rust, dan ekstensi Go (FrankenPHP) sehingga kinerja dapat ditingkatkan secara signifikan di dalam monolitik itu sendiri
• Ekstensi Rust memberikan keamanan memori dan kecepatan sekaligus, sementara FrankenPHP menunjukkan peningkatan kinerja lebih dari 4x lewat worker mode dan ekstensi berbasis Go
• Tanpa harus menanggung biaya dan risiko menulis ulang semuanya ke Go/Rust, pendekatan PHP hibrida memungkinkan tercapainya produktivitas dan kecepatan sekaligus

---

Latar belakang dan arsitektur sebelumnya

• Sebelumnya, pengembangan berpusat pada aplikasi monolitik DDD (mother), lalu microservice berbasis Go (children) dikembangkan secara terpisah untuk mengoptimalkan fungsi tertentu
• Microservice Go menangani pemrosesan trafik berkinerja tinggi, sementara monolitik PHP 8.3 memberikan pengembangan fitur yang cepat dan keandalan deployment dalam lingkungan tim backend kecil
• Struktur ini menawarkan titik keseimbangan yang mampu menghadirkan kecepatan, stabilitas, dan produktivitas sekaligus

Titik bottleneck kinerja dan cara penanganan sebelumnya

• Prinsip Pareto bahwa 80% trafik terkonsentrasi pada 20% endpoint API sering diamati
• Untuk 20% area yang paling penting dari sisi kinerja ini, diterapkan berbagai cara seperti penulisan kode yang dioptimalkan, penambahan lapisan caching, dan pemisahan microservice Go
• Namun, pendekatan ini memiliki keterbatasan dari sisi kompleksitas dan beban operasional

Opsi hibrida dalam ekosistem PHP modern

• Kini semakin banyak teknologi yang memungkinkan peningkatan kinerja langsung di dalam monolitik PHP

• 1. FFI (Foreign Function Interface)

  • Fitur FFI di PHP memungkinkan kode C dipanggil langsung dari PHP
  • Logika level sistem maupun logika kritikal terhadap kinerja dapat diimplementasikan di dalam proyek PHP
  • Namun, penggunaannya disarankan hanya pada situasi yang tepat dengan mempertimbangkan biaya context switching

• 2. Ekstensi berbasis Rust

  • Ekstensi PHP dapat dikembangkan dengan Rust (atau Zig)
  • Area pemrosesan beban tinggi dapat di-offload ke ekstensi Rust yang memiliki stabilitas memori dan kinerja kompilasi, sehingga keandalan dan kecepatan tinggi bisa diperoleh sekaligus

• 3. Ekstensi berbasis Go: FrankenPHP

  • Setelah beralih ke FrankenPHP, saat dijalankan dalam worker mode, terlihat kinerja lebih dari 4x lebih cepat dibanding sebelumnya
  • Rilis terbaru juga memungkinkan penulisan ekstensi PHP dengan Go
  • Dengan ini, kinerja API Go dapat langsung dimanfaatkan di dalam monolitik PHP, sehingga produktivitas dan kecepatan bisa digabungkan tanpa memecah bahasa

Mengapa bukan migrasi total ke Go atau Rust

• Biaya penulisan ulang total dan risikonya sangat tinggi
  • Mengganti sepenuhnya aplikasi yang sudah besar dan stabil ke Go atau Rust membutuhkan risiko dan sumber daya yang besar
• PHP sendiri masih memiliki kekuatan
  • Untuk sebagian besar kebutuhan bisnis, pengembangan cepat, ekosistem yang ramah, dan performa yang cukup cepat dari PHP tetap kompetitif
  • Jika hanya area tertentu yang benar-benar membutuhkan batas performa tertinggi yang disusun secara hibrida dengan Go atau Rust, kebutuhan migrasi total dapat dihilangkan

Kesimpulan: nilai dari PHP hibrida

• Ekosistem PHP modern menyediakan produktivitas pengembangan yang cepat sekaligus opsi integrasi ekstensi berkinerja tinggi (C, Rust, Go)
• Dengan struktur hibrida seperti ini, kecepatan dan produktivitas dapat dicapai bersamaan
• Ini menghadirkan paradigma arsitektur baru yang memungkinkan pengembangan tetap berpusat pada PHP sambil memperluas bahasa secara selektif sesuai kebutuhan

[naearu]

Rasanya ini jadi seperti JavaScript yang sedang berubah.

[skageektp]

Kalau nodejs dengan rust sih mungkin masih masuk akal;; tapi buat saya, karena di PHP hal seperti $ terus dipakai, rasanya mengetik kode jadi tidak nyaman. Buat yang sudah terbiasa memakainya, apakah memang tidak terlalu terasa tidak nyamannya?

[proinworks]

Meskipun terasa tidak nyaman, bukankah kalau terus digunakan kita cepat terbiasa?
Manusia adalah makhluk yang beradaptasi.

[nemorize]

Saya mungkin merasa kurang nyaman dengan konsep variabel/fungsi di PHP itu sendiri, tetapi saya sama sekali tidak pernah merasa tidak nyaman dengan notasi $.

Cerita seperti "saya tidak bisa memakainya karena tanda dolar", "orang yang memakai tanda dolar jadi menghasilkan banyak uang", atau "karena itu dolar Zimbabwe, bukan dolar AS, jadi penghasilannya tidak seberapa" bukankah memang cuma lelucon saja...

[GN⁺]

Komentar Hacker News

• Saya makin tidak suka pada framework serba guna (Spring, Laravel, Phoenix, dll.); awalnya memang sangat produktif, tetapi di proyek legacy masalah yang sama selalu terulang. Karena setiap proyek punya lingkungan infrastruktur atau kondisi bisnis yang berbeda, kita tidak bisa hanya mengikuti cara yang direkomendasikan framework, sehingga tambalan tambahan dan trik dependensi makin menumpuk di mana-mana. Saat ingin upgrade ke bahasa atau versi baru, semua bagian kustom ini jadi rusak, dan akhirnya tak ada yang mau update sampai infrastrukturnya benar-benar tak bisa lagi menjalankannya, lalu terjadilah migrasi besar penuh air mata. Menggabungkan berbagai library dan membuat abstraksi sendiri memang bisa memakan waktu lebih lama, tetapi bisa di-upgrade secara fleksibel per bagian dan memungkinkan perubahan arah dengan cepat. Dalam hal ini saya jadi merasa ekosistem Go ideal; awalnya terasa asing, tapi sekarang justru saya lebih menyukai pendekatan ini.

  • Untuk framework web, saya sangat merasakan pola “awalnya enak sekali, lalu pada suatu titik mulai terasa merepotkan”. Saat membuat aplikasi sederhana, hal seperti Rails dengan “membuat blog dalam 15 menit” terasa seperti sihir, tetapi ketika sistem makin kompleks, framework justru menjadi penghalang. Secara pribadi, saya lebih nyaman dengan setup HTTP “tingkat menengah” seperti Express + Node.js atau Vert.x + Java.

  • Di Python, kita bisa membedakannya menjadi microframework (jenis Flask) dan macroframework (Django). Saya selalu memilih Django; Flask hampir tidak menyarankan apa pun, sehingga setiap proyek menjadi snowflake baru yang dirakit ulang dari nol. Ada kelelahan pengambilan keputusan karena harus memilih dari sekian banyak opsi untuk autentikasi, template, cookie, email, dan sebagainya. Terutama karena kebanyakan library seperti ini dikembangkan oleh satu orang, kualitas pemeliharaan dan keamanannya juga tidak konsisten. Sebaliknya, mayoritas proyek Django bentuknya mirip-mirip dan hampir semua fitur dasar langsung tersedia. Saya hanya perlu memakai library ekstensi kalau memang ada kebutuhan khusus; karena banyak bagian yang dikelola dan diverifikasi secara langsung, saya merasa keandalan kode dan keamanannya juga lebih tinggi.

  • Alasan Go tidak punya framework raksasa adalah karena sistem tipe bahasanya masih sangat belum matang. Membuat library kompleks yang saling cocok satu sama lain itu sulit. Saya bahkan menunggu 9 tahun sampai generics tersedia sebelum akhirnya membuat toolkit database pertama saya untuk Go. Itu berhasil, tetapi sampai membuat saya merasa dulu saat melakukan hal serupa di Java rasanya lebih baik. Kalau tipe hasil bisa di-map/filter/reduce ke tipe generik lain, dunianya akan benar-benar berbeda. Kalau saja ada penetapan union type, kita tidak perlu lagi memakai tipe any. Kalau ada dukungan overloading saja, kodenya akan jauh lebih rapi; sistem tipe Go masih perlu berkembang lebih jauh.

  • Di bidang saya, yang berguna hanya Go dan Rust. Budaya framework yang terlalu opinionated tidak cocok buat saya. Saya rasa Rails, Laravel, dan Django sangat bagus ketika situasinya jelas berupa operasi CRUD database relasional.

  • Selama 5 tahun terakhir saya hanya memakai komponen yang kompatibel dengan PSR (Php Standards Recommendation), dan sama sekali tidak memakai framework. Alasannya karena framework besar pada akhirnya tidak cocok untuk jangka panjang. Terlalu banyak batasan, dan pengelolaan serta update menjadi sangat sulit. Baik untuk proyek perusahaan berskala besar maupun layanan pribadi, saya merasa arsitektur yang berpusat pada komponen PSR lebih baik.

• Saya paham bahwa ketika basis kode sangat besar dan mustahil ditulis ulang sepenuhnya, pendekatan hibrida (menggabungkan PHP dengan bahasa performa seperti C, Rust, Go, dll.) bisa masuk akal. Tapi kalau tidak benar-benar perlu, menurut pengalaman saya API C# bisa mendapatkan kecepatan pengembangan sekaligus performa runtime. Saya hampir tidak pernah perlu sampai ke C++ atau Rust. PHP juga bagus, tetapi masih belum punya hal seperti typed array. Misalnya, ini bahasa yang tidak menolak string masuk ke array tanggal.

  • Saya sudah lama memakai C# dan punya pengalaman dengan berbagai framework web/API. Kalau PHP didalami sedikit, sangat menyenangkan karena punya banyak sekali fungsi bawaan dasar untuk pengembangan web. Memang ada kekurangannya, tetapi kalau harus membuat sesuatu dengan cepat, menurut saya PHP terasa sebagai pemenangnya.

  • Memang benar PHP mengizinkan tipe yang salah di array (misalnya string di array tanggal). Kadang muncul perilaku aneh atau bug. Baru-baru ini saya pernah menemui bug saat hasil json_decode() memiliki key angka yang masuk sebagai int, sementara sisanya sebagai string, sehingga tipe key menjadi campur aduk. Sudut-sudut seperti ini memang agak aneh, tetapi tetap saja PHP sendiri adalah bahasa Frankenstein yang sangat menarik.

  • Sebenarnya kalau memakai static analyzer, error tipe seperti itu biasanya bisa dicegah. Kemungkinan besar dukungan generics juga akan segera masuk ke PHP. Kabar terkait bisa dilihat di blog thephp.foundation.

  • Saya penulis artikelnya, terima kasih sudah membaca. Sebenarnya tidak perlu menulis ulang semuanya; kalau PHP dijalankan dengan runtime berbasis worker seperti swoole atau frankenphp, performanya bisa mencapai level Node. Masalah typed array atau generics juga didukung oleh static analyzer seperti phpstan; kalau memanfaatkan anotasi tipe, stabilitas tipe juga bisa meningkat cukup signifikan.

  • Sejak dukungan VB6 dihentikan, saya memutuskan untuk tidak lagi memakai bahasa Microsoft apa pun. Hanya bahasa open source yang baik untuk kesehatan mental.

• Saat saya masuk ke {{company}}, seluruh perusahaan masih berada di lingkungan PHP 5.4, dan saat itu sentimen anti-PHP sangat kuat. Tetapi setelah merasakan PHP modern, justru pada titik ketika kami hampir meninggalkan PHP sepenuhnya, migrasi ini malah terasa seperti “kemunduran untuk saat ini”. Orang-orang masih menilai PHP berdasarkan era 5.x, padahal sekarang sudah sepenuhnya berbeda.

  • Saya melihatnya sedikit berbeda; kalau melihat pasar kerja, masih ada persepsi tentang PHP (baik atau buruk), dan itu membatasi perekrutan developer unggul. Meskipun secara teknis PHP tidak seburuk dulu, dari sisi branding perusahaan saya tetap merasa keluar dari PHP masih punya nilai.

  • Saya tidak setuju dengan pernyataan “PHP sekarang awesome”; memang jelas membaik, tetapi kata awesome terasa agak berlebihan.

  • PHP makin lama makin bagus, saya jadi berpikir dalam waktu dekat perlu mempelajarinya lebih dalam.

  • Kami juga mengalami dilema yang sama 4 tahun lalu, dan akhirnya tetap lanjut setelah upgrade ke PHP 8. Bagi tim kami, keputusan itu terbukti tepat selama beberapa tahun terakhir.

• Pasir mirip dengan frankenphp tetapi berbasis Rust, sangat menjanjikan tetapi masih pada tahap awal pengembangan.

• Pasir github Pasir memakai konversi binding Zend API ke Rust.

• Zend API Rust binding Ada juga eksperimen menarik seperti ngx-php, dengan struktur yang menanamkan PHP melalui Zend API di dalam biner nginx.

• ngx-php github workerman mewujudkan runtime yang sangat cepat dengan backend hibrida asio.

• workerman github

  • Saya penasaran apakah Pasir, frankenphp, dan sebagainya juga mendukung modul PHP yang sudah ada.

  • Terima kasih atas rekomendasinya, kelihatan benar-benar keren. Tapi seperti yang Anda bilang, saya setuju bahwa ini masih jauh dari level production. Kami akhirnya memilih frankenphp yang didukung oleh php foundation.

• Kompleksitas debugging dan maintenance sering diremehkan, dan kalau ada pilihan, saya rasa lebih baik menghindari kombinasi seperti ini.

  • Terima kasih atas pendapatnya; kami memilih frankenphp, jadi kalau ada alasan mengapa debugging bisa menjadi lebih sulit, tolong jelaskan secara spesifik.

• Saya juga pernah mengganti aplikasi saya dari PHP ke Go, dan itu merupakan investasi yang berhasil bagi perusahaan. Kode PHP sebanyak 20 ribu baris berkurang menjadi 4 ribu baris di Go, dan efisiensinya juga meningkat besar. Kalau Anda perusahaan PHP, saya sangat menyarankan untuk merencanakan rewrite besar-besaran dan menjalankannya bersamaan dengan penambahan test (yang lebih mudah di Go). Menurut saya itu lebih baik daripada menderita memelihara campuran banyak bahasa seperti Rust/PHP atau Go/PHP.

  • Saya penasaran bagaimana jumlah baris kode bisa berkurang sebanyak itu saat pindah dari PHP ke Go. Saya merasa Go bahasa yang sangat verbose; dalam pengalaman saya, PHP ada di tengah-tengah, Haskell paling ringkas, sedangkan Java/Go justru cenderung lebih panjang karena hal seperti error handling.

  • Saya sulit menerima klaim bahwa pindah dari PHP ke Go bisa menurunkan jumlah baris sampai 5 kali lipat. Saya merasa PHP punya banyak sintaks singkat, sementara Go tidak terlalu punya itu.

  • Saya rasa poin pentingnya selalu apakah peningkatan performa dan efisiensi setelah rewrite itu “karena bahasanya” atau “karena perbaikan arsitektur yang diterapkan saat ditulis ulang”.

  • Saat rewrite ke Go, saya sempat mengira pola if err != nil justru akan membuat kode membengkak 10 kali lipat. Saya pernah mengalami rewrite ke Python, dan di Python pun kode jadi sangat verbose, sementara pola seperti dependency injection terasa merepotkan saat testing.

  • Saya tidak merekomendasikan rewrite secara mutlak (meskipun saya pernah dua kali berhasil menyelesaikannya, saya sendiri tetap mungkin tidak akan memilihnya). Runtime PHP modern sekarang benar-benar cepat, jadi tetap layak dicoba. Terutama kalau memanfaatkan seluruh task cache seperti di swoole, kadang bisa secepat Go juga (disarankan melihat benchmark).

• Kadang saya merasa kita benar-benar perlu kembali ke dasar: piksel, data, latensi/bandwidth. Pada akhirnya web juga hanyalah “masalah optimisasi untuk menampilkan piksel yang benar ke mata manusia dengan kecepatan yang terasa cepat, di dalam batas sumber daya jaringan”. Saya merasa pendekatan seperti “piksel apa yang akan segera dilihat pengguna?”, “data apa yang diperlukan untuk menggambarkannya?”, “perlukah prefetch data yang kemungkinan akan dipakai berikutnya?” memang cara berpikir yang tepat.

  • Saya sedang membuat alumina-ui dengan egui untuk WASM, dan tanpa pengetahuan web yang rumit seperti HTML, JavaScript, atau CSS, saya cukup menyediakan satu canvas berukuran sesuai browser lalu langsung merender dengan WebGL. Sangat praktis karena saya bisa menghasilkan grafis cepat dengan akselerasi GL dalam bahasa yang saya suka. Saya sangat menyukai WASM/WebGL karena abstraksi seperti ini.

  • Terlalu sempit kalau hanya fokus pada piksel yang dilihat pengguna. Dalam proyek software, yang perlu dioptimalkan bukan hanya UX yang langsung terasa, tetapi juga waktu pengembangan. Delay sampai layar pertama muncul dan waktu pengembangan aktual sama sekali tidak berbanding lurus.

• FrankenPHP terlihat sangat menarik, tetapi dalam praktiknya agak nyentrik. Tidak ada yang memakai PHP tanpa modul PHP, daftar modul PHP yang didukung FrankenPHP juga tidak jelas, dan saya juga tidak tahu apakah saya bisa membangun serta menambahkan modul terpisah yang saya inginkan. Ia sangat terkait erat dengan Caddy, sementara saya tidak terbiasa dengan web server ini dan lebih suka nginx. Karena tidak ada panduan, saya juga tidak tahu apakah ini bisa dipakai sebagai pengganti php-fpm di nginx. Selain itu, image Docker Caddy atau FrankenPHP seolah hanya memikirkan sertifikat Let's Encrypt, sehingga kalau ingin mengonfigurasi SSL sendiri atau menjalankan hanya dengan HTTP, rasanya benar-benar tidak intuitif.

  • Soal modul PHP, biasanya dibangun langsung di dalam Dockerfile. Misalnya untuk menambahkan modul pgsql, caranya dengan memasang dependensi lewat apt, memasang modul lewat docker-php-ext-install, lalu menghapus dependensi dan membersihkan setelahnya. Konfigurasi HTTP juga bisa langsung dibuka di port 80 lewat Caddyfile.

  • Static build pada dasarnya sudah menyertakan puluhan modul utama PHP. Daftar modul detail dan skrip build bisa dilihat di frankenphp build-static.sh.

• Saya penasaran pada jenis workload apa ekstensi bahasa seperti C/Rust/Go benar-benar dibutuhkan. Saya paham itu ada gunanya, tetapi saya juga ingin tahu lebih jelas kenapa kompleksitas ini perlu ditambahkan ke stack dan apakah memang tidak bisa diselesaikan dengan cara lain.

• Hal yang paling saya benci dari PHP adalah setiap permintaan HTTP membuat seluruh aplikasi melakukan bootstrap sekali, autoloading dijalankan, dan konfigurasi dievaluasi ulang. Memang ada cache dan sebagainya, tetapi dibanding model seperti Go yang mesinnya selalu hidup, itu tetap terasa sulit diterima.

  • Sebenarnya ada cukup banyak library yang terdokumentasi dengan baik untuk menjalankan server mandiri hanya dengan PHP, dan cukup layak dipakai di production. Performa JIT PHP juga cukup mengesankan.

• reactphp.org

• php.net ev module

• pecl-event

• workerman.net

  • Tidak harus begitu (dijalankan ulang pada setiap request). Beberapa runtime PHP mendukung satu eksekusi skrip untuk menangani banyak request HTTP.

• dokumentasi worker frankenphp

  • Justru saya menganggap ini kelebihan terbaik PHP. Scale-out menjadi sangat mudah.

  • Saya justru suka struktur seperti ini. State secara inheren diminimalkan (sampai tingkat tertentu).

  • Kamu benar, cara ini memang benar-benar buruk. Terutama lebih bermasalah lagi ketika PHP dipakai sebagai bahasa template itu sendiri. Template engine kustom atau runtime yang berjalan terus-menerus untuk memperbaikinya pada akhirnya tetap cuma “lipstik pada babi”. Seharusnya sejak awal kita memilih bahasa yang namanya bukan Personal HomePage.