Hibrit PHP'nin Yükselişi: PHP'nin Go ve Rust ile Birleşimi

 (yekdeveloper.com)
14 puan yazan GN⁺ 2025-09-02 | 5 yorum | WhatsApp'ta paylaş
  • Son dönemde PHP monolitik yapısı içinde Go ve Rust'ı uzantı dili olarak entegre eden hibrit yaklaşım dikkat çekiyor
  • Önceden Go mikroservisleri ile PHP 8.3 monolitik yapısının birleşimiyle üretkenlik ve yüksek performans dengeli biçimde sağlanıyordu
  • Pareto ilkesi (%80 trafiğin %20 API'ye yoğunlaşması) uyarınca hotspot endpoint'leri optimize etmek şarttı; geçmişte buna cache'leme ve Go servislerini ayırma ile yanıt veriliyordu, ancak bu da karmaşıklığı artırıyordu
  • Son dönemde PHP ekosistemindeki gelişmelerle FFI, Rust uzantıları, Go uzantıları (FrankenPHP) gibi teknikler ortaya çıktı ve monolitik yapı içinde performansı büyük ölçüde artırmak mümkün hale geldi
  • Rust uzantıları bellek güvenliği ile hızı aynı anda sunarken, FrankenPHP worker mode ve Go tabanlı uzantılarla 4 katın üzerinde performans artışı gösteriyor
  • Her şeyi Go/Rust ile yeniden yazmanın maliyet ve riskinden kaçınırken, hibrit PHP yaklaşımıyla hem üretkenlik hem de hız elde edilebiliyor

Arka plan ve mevcut mimari

  • Mevcut yapıda, DDD monolitik uygulama (mother) merkeze alınıyor ve belirli işlevleri optimize etmek için Go tabanlı mikroservisler (children) ayrı olarak geliştiriliyordu
  • Go mikroservisleri yüksek performanslı trafik işleme görevini üstlenirken, PHP 8.3 monolitik yapı küçük backend ekiplerinde hızlı özellik geliştirme ve güvenilir dağıtım sağlıyordu
  • Bu yapı, hız, istikrar ve üretkenliği aynı anda sağlamak için dengeli bir nokta sunuyordu

Performans darboğazları ve önceki yaklaşım

  • Trafiğin %80'inin API endpoint'lerinin %20'sinde yoğunlaştığı Pareto ilkesi sıkça gözlemleniyordu
  • Performansın en kritik olduğu bu %20'lik bölüm için optimize kod yazma, cache katmanı ekleme, Go mikroservislerine ayırma gibi çeşitli yöntemler kullanıldı
  • Ancak karmaşıklık ve operasyon yükü açısından bunların sınırları vardı

Güncel PHP ekosistemindeki hibrit seçenekler

  • Son dönemde performansı doğrudan PHP monolitik yapısının içinde iyileştirebilen teknolojilerin sayısı arttı

  • 1. FFI (Foreign Function Interface)

    • PHP'nin FFI özelliği sayesinde PHP içinden C kodu doğrudan çağrılabiliyor
    • Sistem seviyesi ya da performans açısından kritik mantık da PHP projesi içinde uygulanabiliyor
    • Ancak context switching maliyeti dikkate alınmalı; bu yüzden yalnızca uygun senaryolarda kullanılması öneriliyor
    Reklam

  • 2. Rust tabanlı uzantılar

    • Rust (veya Zig) ile PHP uzantıları geliştirilebiliyor
    • Yüksek yük altındaki bölümler, bellek güvenliği ve derlenmiş performans sunan Rust uzantılarına offload edilerek hem güvenilirlik hem de yüksek hız elde edilebiliyor

  • 3. Go tabanlı uzantılar: FrankenPHP

    • Yakın zamanda FrankenPHP'ye geçildikten sonra worker mode'da çalıştırıldığında önceye kıyasla 4 katın üzerinde daha hızlı performans görüldü
    • Son sürümlerle birlikte Go ile PHP uzantısı yazmak da mümkün hale geldi
    • Böylece Go'nun API performansı doğrudan PHP monolitik yapısı içinde kullanılabiliyor; dili bölmeden üretkenlik ve hızı birleştirmek mümkün oluyor
Reklam

Neden tamamen Go veya Rust'a geçilmiyor?

  • Tam yeniden yazımın maliyeti ve risk yükü yüksek
    • Zaten büyük ve kararlı bir uygulamayı tamamen Go veya Rust'a geçirmek ciddi risk ve kaynak tüketimi yaratıyor
  • PHP'nin hâlâ güçlü yanları var
    • Çoğu iş yükünde PHP'nin hızlı geliştirme yapısı, erişilebilir ekosistemi ve yeterince hızlı performansı hâlâ rekabetçi
    • Gerçek performans sınırlarının gerektiği bazı alanlarda yalnızca Go ve Rust ile hibrit yapı kurmak, tüm sistemi taşıma gereğini ortadan kaldırabiliyor

Sonuç: Hibrit PHP'nin değeri

  • Modern PHP ekosistemi, hızlı geliştirme üretkenliğiyle birlikte yüksek performanslı (C, Rust, Go) uzantı entegrasyonu seçeneklerinin tümünü sunuyor
  • Bu hibrit yapı sayesinde hem hız hem de üretkenlik elde edilebiliyor
  • PHP merkezli geliştirme korunurken, gerektiğinde dillere göre seçici genişleme yapılabilen yeni bir mimari paradigma ortaya konuyor

İlgili okumalar

5 yorum

 
naearu 2025-09-02

Sanki JavaScript'in değişmesi gibi bir yöne evriliyor gibi görünüyor.
 
skageektp 2025-09-02

nodejs’te Rust olsa neyse de;; bence PHP’de $ gibi şeylerin sürekli kullanılması kod yazmayı rahatsız edici gösteriyor; ama iyi kullananlar bunu çok da rahatsız edici bulmuyor mu?
 
proinworks 2025-09-03

Rahatsızlık hissetseniz bile kullanmaya devam ettikçe buna çabucak alışmıyor musunuz?
İnsan, uyum sağlayan bir canlıdır.
 
nemorize 2025-09-02

Ben PHP’nin değişken/fonksiyon kavramlarının kendisinden rahatsızlık duymuş olabilirim ama $ gösteriminden hiçbir zaman rahatsızlık duymadım.

Dolar işareti yüzünden kullanamıyorum, ~~dolar işareti kullananlar çok para kazanıyor, Amerikan doları değil de Zimbabve doları olduğu için o kadar da kazanamıyorlar~~ gibi laflar espri olsun diye söylenen şeyler değil miydi...
 
GN⁺ 2025-09-02
Hacker News yorumu

  • Giderek genel amaçlı framework'lere (Spring, Laravel, Phoenix vb.) karşı antipati geliştirdim; başta gerçekten çok üretkenler ama legacy projelerde hep aynı sorunlar tekrar ediyor. Her projenin altyapı ortamı ya da iş koşulları farklı olduğu için, framework'ün önerdiği yolla birebir ilerleyemiyorsunuz; sonuçta oraya buraya ek yamalar ve bağımlılık hileleri birikiyor. Yeni bir dile ya da sürüme yükseltmeye kalktığınızda bu özelleştirilmiş parçaların hepsi bozuluyor; sonunda da kimse güncelleme yapmıyor ve ancak altyapıda artık çalışamaz hale gelince gözyaşları içinde büyük bir göç yaşanıyor. Birden fazla kütüphaneyi birleştirip kendi soyutlamanızı kurmak daha uzun sürebilir ama parçalı ve esnek yükseltme yapabilmenizi sağlıyor, ayrıca hızlı yön değiştirmek de mümkün oluyor. Go ekosisteminin bu açıdan ideal olduğunu düşünmeye başladım; başta yabancı gelmişti ama şimdi bu yaklaşımı daha çok seviyorum.

    • Web framework'leri konusunda “başta harika, sonra bir noktadan itibaren rahatsız edici” hissi çok baskın. Basit bir uygulama yaparken Rails'in “15 dakikada blog yap” tarzı yaklaşımı büyü gibi geliyor ama iş karmaşıklaşınca framework bizzat engel haline geliyor. Şahsen Express + Node.js ya da Vert.x + Java gibi “orta seviye” HTTP kurulumlarını daha rahat buluyorum.

    • Python'da microframework'ler (Flask türü) ve macroframework'ler (Django) diye ayırabilirsiniz. Ben her zaman Django'yu seçiyorum; Flask neredeyse hiçbir şey önermediği için her proje baştan ayrı ayrı süslenmiş bir snowflake'e dönüşüyor. Kimlik doğrulama, template, cookie, e-posta vb. için N tane seçenek arasından neyi seçeceğinize karar verme yorgunluğu oluşuyor. Özellikle bu kütüphanelerin çoğu tek kişi tarafından geliştirildiğinden bakım/güvenlik kalitesi de çok değişken olabiliyor. Buna karşılık Django'da projelerin çoğu birbirine benziyor ve neredeyse tüm temel özellikler kutudan çıkar çıkmaz geliyor. Benim ayrıca bir genişletme kütüphanesi kullanmam ancak özel gereksinimler varsa anlamlı oluyor; doğrudan yönetilen ve doğrulanmış parça sayısı fazla olduğu için kod güvenilirliği ve güvenliğin de daha yüksek olduğunu düşünüyorum.

    • Go'da devasa framework'lerin olmamasının nedeni, dilin tip sisteminin hâlâ epey eksik olması. Birbiriyle iyi çalışan karmaşık kütüphaneler üretmek zor oluyor. Generic'leri kullanabilmek için 9 yıl bekledikten sonra Go için ilk veritabanı toolkit'imi yapabildim. Başarılı oldu ama Java'da benzer şeyleri yaptığım dönemlerin daha iyi olduğunu düşündürecek kadar zordu. Sonuç tiplerini başka generic tiplerle map/filter/reduce edebilsek bambaşka bir dünyada olurduk. Sadece union type tanımlama desteği gelse bile any kullanmaya gerek kalmazdı. Overloading desteği olsa kod çok daha temiz olurdu; Go tip sisteminin daha gelişmesi gerekiyor.

    • Benim alanımda yalnızca Go ve Rust işe yarıyor. Keskin tercihleri olan framework kültürü bana uymuyor. Rails, Laravel ve Django'nun ilişkisel DB üzerinde CRUD işlerinin net olduğu durumlarda harika olduğunu düşünüyorum.

    • Son 5 yıldır yalnızca PSR (Php Standards Recommendation) uyumlu bileşenler kullanıyorum; hiç framework kullanmıyorum. Sebebi, büyük framework'lerin uzun vadede sonunda uymamaya başlaması. Kısıtları çok oluyor, yönetmek ve güncellemek aşırı zorlaşıyor. İster şirket için büyük bir proje olsun ister kişisel bir servis, PSR bileşenleri merkezli mimarinin daha iyi olduğunu düşünüyorum.

  • Kod tabanı çok büyükse ve her şeyi baştan yazmak imkânsızsa hibrit yaklaşımın (C, Rust, Go gibi performans dilleriyle PHP'yi birlikte kullanmak) anlamlı olabileceğini anlıyorum. Ama mecbur değilseniz, deneyimime göre C# API tarafında geliştirme hızıyla çalışma performansını aynı anda yakalayabiliyor. Neredeyse hiç C++ ya da Rust'a gitmem gerekmedi. PHP de iyi ama hâlâ typed array gibi şeyler yok. Mesela tarih dizisine string gelse bile reddetmeyen bir dil.

    • C# ile uzun süre çalıştım ve çeşitli web/API framework'leri kullandım. PHP'yi biraz derinlemesine inceleyince, web geliştirme için temel gömülü fonksiyonlarının gerçekten çok fazla olması hoşuma gitti. Eksileri var ama bir şeyi hızlıca ortaya çıkarmanız gerektiğinde bana göre kazanan PHP oluyor.

    • PHP'nin array içinde yanlış tiplere (ör. tarih dizisine string) izin verdiği doğru. Bazen garip davranışlar ya da bug'lar ortaya çıkıyor. Yakın zamanda json_decode() ile decode ettiğimde anahtar değeri sayıysa int, değilse string geldiği için anahtar tiplerinin karıştığı bir bug yaşamıştım. Bu köşe bucak ayrıntılar biraz tuhaf olabilir ama buna rağmen PHP gerçekten çekici bir Frankenstein dili.

    • Aslında statik analiz aracı kullanırsanız bu tür tip hataları engelleniyor. PHP'ye generic desteğinin de yakında gelme ihtimali yüksek. İlgili haberi thephp.foundation blogunda görebilirsiniz.

    • Yazının yazarı benim, okuduğunuz için teşekkürler. Aslında her şeyi baştan yazmak gerekmiyor; PHP'yi swoole ya da frankenphp gibi worker tabanlı runtime'larda çalıştırırsanız Node seviyesinde performans alabilirsiniz. Typed array ya da generic sorunları da phpstan gibi statik analiz araçları destekliyor; type annotation kullanırsanız tip güvenliğini ciddi biçimde artırabilirsiniz.

    • VB6 desteği bittikten sonra Microsoft dillerini tamamen bırakmaya karar verdim. Ruh sağlığı için iyi olan tek seçenek açık kaynak diller.

  • {{company}}'ye girdiğimde şirket genelinde PHP 5.4 kullanılıyordu ve o zamanlar PHP'ye karşı ciddi bir hoşnutsuzluk vardı. Ama modern PHP'yi görünce, tam da artık PHP'den uzaklaşmak üzere olduğumuz bu noktada yapılan bu göçün aslında “şimdi bakınca geriye gidiş” gibi hissettirdiğini söyleyebilirim. İnsanlar hâlâ PHP'yi 5.x dönemine göre değerlendiriyor ama bugün bambaşka bir şey.

    • Ben biraz farklı düşünüyorum; işe alım piyasasına baktığınızda PHP hakkındaki algı (iyi ya da kötü) hâlâ etkili ve iyi geliştiricileri çekme konusunda sınırlayıcı olabiliyor. Teknik olarak PHP eskisi kadar kötü olmasa bile, şirket markası açısından PHP'den çıkmanın hâlâ anlamlı olduğunu düşünüyorum.

    • “PHP artık awesome” sözüne katılmıyorum; kesinlikle iyileşti ama awesome demek biraz fazla.

    • PHP giderek daha iyi hale geliyor; yakında daha derin bakmam gerektiğini düşünüyorum.

    • Biz de 4 yıl önce aynı tartışmayı yaşadık ve sonunda PHP 8'e yükseltip devam etmeye karar verdik. Bu seçim son birkaç yılda ekibimiz için oldukça iyi çalıştı.

  • Pasir, frankenphp'ye benziyor ama Rust tabanlı; çok umut verici görünüyor ancak henüz geliştirme sürecinin başında.

  • Pasir github Pasir, Zend API binding'lerinin Rust'a çevrilmiş halini kullanıyor.

  • Zend API Rust binding'leri ngx-php gibi ilginç deneyler de var; yapı olarak nginx binary'sinin içine Zend API üzerinden PHP gömülmüş durumda.

  • ngx-php github workerman, asio hibrit backend kullanarak çok hızlı bir runtime gerçekleştiriyor.

  • workerman github

    • Pasir ve frankenphp gibi çözümlerin mevcut PHP modüllerini de destekleyip desteklemediğini merak ediyorum.

    • Öneri için teşekkürler, gerçekten çok havalı görünüyor. Ama dediğiniz gibi üretim seviyesi için hâlâ erken olduğuna katılıyorum. Biz, php foundation tarafından desteklenen frankenphp'yi nihai seçim olarak belirledik.

  • Debug ve bakım karmaşıklığı çoğu zaman göz ardı ediliyor; eğer seçme şansınız varsa böyle kombinasyonlardan kaçınmanın daha iyi olduğunu düşünüyorum.

    • Görüş için teşekkürler, frankenphp seçtik; debug'ın neden daha zorlaşabileceğini biraz daha somut anlatabilir misiniz?

  • Ben de uygulamamı PHP'den Go'ya yeniden yazdım ve bu şirket için başarılı bir yatırım oldu. 20 bin satırlık PHP kodunu 4 bin satırlık Go koduna indirdik ve verimliliği de ciddi biçimde artırdık. PHP şirketiyseniz, kapsamlı bir yeniden yazımı planlayıp buna test eklemeyi de (Go'da daha kolay) mutlaka düşünmenizi öneririm. Rust/PHP ya da Go/PHP gibi çok dilli bir yapıyı sürdürüp bakım acısı çekmektense bu daha iyi.

    • PHP'den Go'ya geçerken satır sayısını nasıl bu kadar düşürdüğünüzü merak ediyorum. Go bana oldukça ayrıntılı bir dil gibi geliyor; benim deneyimimde PHP orta seviyedeydi, en sıkı dil Haskell'di, Java/Go ise özellikle hata yönetimi gibi nedenlerle daha da uzuyordu.

    • PHP'den Go'ya geçişte satır sayısının 5 kat azalmasına pek ikna olmadım. PHP'de çeşitli kısa yazım olanakları var ama Go'da bunların pek olmadığını düşünüyordum.

    • Yeniden yazım sonucunda performans ve verimin artmasının “dilden mi, yoksa yeniden tasarıma eklenen mimari iyileştirmelerden mi” kaynaklandığı her zaman önemli bir nokta.

    • Go ile yeniden yazarken if err != nil yüzünden kodun 10 katına çıkacağını sanmıştım. Ben Python'a yeniden yazım yaşadım; Python'da da kod çok ayrıntılı hale geliyor ve dependency injection gibi kalıplar testlerde zahmetli olabiliyor.

    • Ben herkese yeniden yazımı önermem (iki kez başarılı biçimde yeniden yazım tamamladım ama yine de kendim doğrudan tercih etmem). Bugünün PHP runtime'ları gerçekten çok hızlı, o yüzden denemeye değer. Özellikle swoole gibi görev cache'lerini tam kullanırsanız Go kadar hızlı olduğu durumlar bile var (benchmark'lara bakmanızı öneririm).

  • Bazen gerçekten temellere dönmemiz gerektiğini düşünüyorum: piksel, veri, gecikme/bant genişliği. Web de sonuçta “doğru pikselleri insan gözüne yeterince hızlı, ağ kaynakları sınırları içinde çizme” optimizasyon problemi. “Bir sonraki anda kullanıcının göreceği piksel ne?”, “Bunu çizmek için hangi veri gerekiyor?”, “Yakında lazım olabilecek veriyi önceden prefetch etmeli miyim?” gibi sorularla yaklaşmak gerektiğini düşünüyorum.

    • alumina-ui'yi WASM için egui ile yapıyorum, HTML, JavaScript, CSS gibi karmaşık web bilgilerine hiç girmeden, sadece tarayıcıya uygun boyutta bir canvas verip doğrudan WebGL ile render ediyorsunuz. Sevdiğim dille hızlı ve GL hızlandırmalı grafik üretebildiğim için çok kullanışlı buluyorum. WASM/WebGL'i bu tür soyutlamalar sayesinde gerçekten çok seviyorum.

    • Kullanıcının gördüğü piksellere odaklanmak fazla dar bir bakış. Yazılım projelerinde yalnızca anlık UX'i değil, geliştirme süresini de optimize etmeniz gerekir. İlk ekranın görünmesine kadar geçen gecikme ile gerçek geliştirme süresi asla birebir orantılı değildir.

  • FrankenPHP oldukça ilginç görünüyor ama pratikte biraz tuhaf. Kimse PHP modülü olmadan PHP kullanmıyor; FrankenPHP'nin hangi PHP modüllerini desteklediği de net değil, ayrıca benim istediğim ek modülleri derleyip ekleyebiliyor muyum o da belirsiz. Caddy ile çok sıkı bağlı görünüyor; ben bu web sunucusuna alışık değilim, nginx'i tercih ederim. Rehber olmadığı için nginx içinde php-fpm yerine kullanılıp kullanılamadığını da bilmiyorum. Ayrıca Caddy ya da FrankenPHP Docker image'ları sanki yalnızca Let's Encrypt sertifikalarını varsayıyor; kendi SSL kurulumunuzu yapmak ya da sadece HTTP ile çalıştırmak isterseniz hiç sezgisel görünmüyor.

    • PHP modülü konusu genelde Dockerfile içinde elle build edilerek çözülüyor. Örneğin pgsql modülü eklemek için apt ile bağımlılıkları kurup docker-php-ext-install ile modülü yüklüyor, sonra bağımlılıkları kaldırıp temizlik yapıyorsunuz. HTTP ayarı da Caddyfile içinde doğrudan 80 portunu açarak yapılabiliyor.

    • Statik build varsayılan olarak onlarca önemli PHP modülüyle birlikte geliyor. Ayrıntılı modül listesi ve build script'i için frankenphp build-static.sh'ye bakabilirsiniz.

  • Hangi tür workload'larda C/Rust/Go gibi dillerle genişletmeye gerçekten ihtiyaç duyulduğunu merak ediyorum. Buna ihtiyaç duyulabileceğini anlıyorum ama bu karmaşıklığı stack'e neden eklemek gerektiğini ve başka yollarla neden çözülemediğini daha iyi anlamak isterim.

  • PHP'de en sevmediğim şey, her HTTP isteğinde tüm uygulamanın bir kez daha bootstrap edilmesi, autoload yapılması ve yapılandırmanın yeniden değerlendirilmesi. Elbette cache vb. şeyler var ama yine de motorun Go'daki gibi sürekli ayakta kaldığı modele kıyasla mantıklı gelmiyor.

    • Aslında yalnızca PHP ile bağımsız sunucu çalıştırmayı sağlayan, iyi dokümante edilmiş ve üretimde kullanılabilir epey kütüphane var. PHP'nin JIT performansı da oldukça etkileyici.

  • reactphp.org

  • php.net ev module

  • pecl-event

  • workerman.net

    • Bunu mutlaka o şekilde yapmak zorunda değilsiniz. Bazı PHP runtime'ları tek bir script çalışmasının birden fazla HTTP isteğini işlemesini destekliyor.

  • frankenphp worker belgeleri

    • Ben ise bunun PHP'nin en büyük avantajı olduğunu düşünüyorum. Scale-out inanılmaz kolaylaşıyor.

    • Ben de tam tersine bu yapıyı seviyorum. Doğası gereği durumu en aza indiriyor (en azından belli bir seviyeye kadar).

    • Haklısın, bu yaklaşım gerçekten berbat. Özellikle PHP kendi template dili olarak kullanıldığında daha da sorunlu oluyor. Bunu düzeltmeye çalışan özel template engine'leri ya da sürekli çalışan runtime'lar da sonuçta sadece 'ruj sürülmüş domuz' gibi geliyor. En baştan adı Personal HomePage olmayan bir dil seçmek daha doğru olurdu.