Python Web Framework'leri İçin Yeni Bir Düşünce Biçimi

Şu soruyu düşünün: Python web framework'ünüz neden uygulama kodunuzla hiç alakası olmayan işlerle bu kadar meşgul?

FastAPI, Starlette'in üzerine kuruluyor. Starlette, uvicorn'un üzerinde çalışıyor. Uvicorn ise her şeyi soket ile handler'ınız arasında koşturan bir asyncio event loop'unu sarıyor. Her istek—iş mantığınıza henüz ulaşmadan—birden fazla Python katmanından geçiyor, Python'da serializasyon yapılıyor ve her istek için aynı şekilde çalışan Python kodu üzerinden yönlendiriliyor.

Peki ya bu değişseydi? Framework—yani hangi uygulamayı yaparsanız yapın aynı kalan kısım—tamamen Rust'ta yaşasaydı ve Python sadece sizin için gerçekten benzersiz olan kodları çalıştırsaydı?

İşte JustAPI'nin temel fikri bu. Bir süre projeyle haşır neşir olduktan sonra, sadece ne yaptığını değil mimari kararların neden önemli olduğunu da anlamaya değer olduğunu düşünüyorum.

Performans Rakamları: Sadece Sayılar Değil

Mimariye dalmadan önce sayılardan bahsedelim—çünkü bağlam olmadan performans iddiaları mühendislik değil, pazarlama oluyor.

Proje, basit bir hello-world testinde saniyede 766.000 istek işledi. 500 rotalı bir konfigürasyonda yönlendirme işlemleri yaklaşık 51 nanosaniye sürüyor. Multi-threaded Tokio ve free-threaded CPython desteğiyle async throughput 14 kat artmış.

Peki bu rakamlar size ne ifade ediyor? Saniyede binlerce istek işleyen bir API çalıştırıyorsanız, bu iyileştirmeler katlanarak artar. Düşük latency, kullanıcılarınızın daha az beklemesi demek. Yüksek throughput, sunucularınızın daha fazla yükü kaldırması demek. Ama asıl hikaye ham sayılar değil—yönetmek zorunda olmadığınız şeyler.

uvicorn yok. Gunicorn yok. Gece saat 3'te bir şeyler ters gittiğinde debug edeceğiniz ASGI middleware yığını yok. Tüm istek pipeline'ı Rust'ta çalışıyor ve Python kodunuz sadece... kodunuz.

Mimari: Python İstisna, Rust Kural

İstek yolu şöyle işliyor: Kernel (epoll/io_uring) → Tokio connection manager → rustls ile TLS → Hyper ile HTTP parsing → Router (matchit radix trie) → Middleware chain (auth, CORS, rate-limiting) → PyO3 üzerinden Python sınırı → Handler'ınız → Rust serializer → Response.

Python'un girdiği yere dikkat edin: sadece uygulama mantığınız başladığında. Öncesindeki her şey—her istek için aynı şekilde çalışan her şey—Rust.

Bu ayrım önemli. JustAPI'nin arkasındaki geliştirici, geliştirme sürecinde basit bir kural koymuş: bir özellik Rust'ta implement edilebiliyorsa, Rust'ta implement edilmeli. "Rust'ta daha hızlı olabilir" değil—"Rust'ta implement edilebilir". Python, Rust değerleri ile handler'larınız arasındaki yapıştırıcıya ayrılmış.

Bu kısıtlama tüm projeyi şekillendirmiş ve Rust parçaları sonradan eklenmiş diğer Python framework'lerinden gerçekten farklı bir şey ortaya çıkarmış.

Geliştirici Deneyimi Açısından Ne Anlama Geliyor?

Başlangıç aşamasındaki şirketler ve büyüyen ekipler için bu yaklaşımın ilginçleştiği yer burası.

HTTP/1.1 ve HTTP/2, TLS, parametreli yönlendirme, JSON serializasyonu, otomatik OpenAPI dokümantasyonu dahil eksiksiz bir API framework'ü elde ediyorsunuz—ve bunu gerçekten Python gibi görünen 30 satır kodla:

from justapi import JustAPIApp

app = JustAPIApp()

@app.get("/")
def hello():
    return {"Merhaba": "Dünya"}

app.run()

Ama bu tanıdık yüzeyin altında, TLS'yi halleden, bağlantıları yöneten ve Python'a hiç geçmeden response'ları serialize eden bir Rust sunucusu çalışıyor. Geliştirici deneyimi Python tarzında kalıyor. Runtime performansı ise Rust.

MVP oluşturup sonradan scale etmesi gerekecek ekipler için bu önemli. Bugün Python ile yazıyorsunuz. Daha fazla yükü kaldırmanız gerektiğinde hiçbir şeyi yeniden yazmadan Rust performansı elde ediyorsunuz.

AI Faktörü: Bir Yardımcı, Değil Yerine Geçen

Bu proje, agentic AI'yı aktif bir katılımcı olarak inşa edilmiş—autocomplete olarak değil, mimariyi tasarlamaya, kararları koda dönüştürmeye, bugları bulmaya ve test yazmaya yardımcı olan bir mühendislik ortağı olarak.

Bu konuyu açıkça konuşmaya değer, çünkü giderek yaygınlaşıyor ama nadiren şeffaf bir şekilde konuşuluyor.

Geliştirici, kod tabanını üç katmanda tanımlıyor: tamamen anladığı kısımlar, bakımını yapabilecek kadar anladığı kısımlar ve AI'nın yazdığı, inceleyip test ettiği ama hafızasından yeniden üretemediği kısımlar. Bu, projenin var olma biçiminin bir parçası olduğunu açıkça söylüyor.

Bence doğru çerçeveleme bu. AI araçları karmaşık projelerde geliştirmeyi hızlandırıyor ve bunu inkâr etmek kimseye yardımcı olmuyor. Mesele, neye sahip olduğunuzla neye delege ettiğiniz arasındaki farkı anlamak ve hangisinin hangisi olduğu konusunda dürüst olmak.

Pratik Çıkarım

JustAPI gibi framework'ler, Python'un yüksek performanslı sistemlerdeki rolü hakkındaki düşünce biçimimizde bir değişimi temsil ediyor. Python, uygulama mantığı için her zamankinden daha değerli—okunabilirliği ve ekosistemı çok önemli. Ama framework'ün kendisinin Python'da çalışması gerektiği varsayımı sorgulanıyor.

JustAPI bir sonraki framework'ünüz mü olur yoksa ilginç bir deneyim olarak mı kalır, bilinmez ama altındaki temel fikir değerli: her istekte aynı şekilde çalışan şeylere bakın. Burası muhtemelen Rust bölgesi. Değişen kısımlar mı? Onları ekibinizin en verimli çalıştığı dilde tutun.

"Çalışıyor" ile "İyi çalışıyor" arasındaki fark giderek daralıyor. Kullanıcılarınız mimariyi fark etmeyecek ama latency'yi fark edecekler.

İleriye Bakış

JustAPI şu anda 2.0.10 sürümünde. Belgelenmiş özellikler arasında WebSockets, SSE, arka plan görevleri, scheduler, SQLx üzerinden veritabanı erişimi ve OpenTelemetry ile Prometheus metrikleri gibi operasyonel araçlar var. Standart Linux, macOS, Windows ve free-threaded CPython 3.14t build için PyPI'de wheels olarak mevcut.

Rakamlar repoda var. Testler geçiyor. Hatalar belgelenmiş. Teşvik etmemiz gereken bu tür bir mühendislik şeffaflığı.

Python API'leri oluşturuyorsanız ve performans sizin için önemliyse, bir göz atmaya değer. Python web framework'lerinin geleceği, bugün kullandığınız şeye benzemeyebilir.