- Rust ile küçük bir web uygulaması yaparken bile Django benzeri entegre bir deneyim eksik; yönlendirme, giriş, veritabanı ve yönetim işlevlerini elde elle birleştirme yükü büyüyor
- Gereken framework; yönlendirme/handler’lar, şablonlar, statik dosya sunumu, giriş, yetkilendirme, veritabanı arayüzü, yönetim araçları, WebSockets ve hot reloading özelliklerini varsayılan olarak bir arada sunmalı
- actix-web ve axum gibi minimal framework’ler ile Dioxus, Leptos, Yew gibi SPA framework’leri var; ancak bunlar tam bir web uygulaması yapısını sizin yerinize bir araya getirmiyor
- Başlangıç şablonları ilk kurulumu azaltsa da, proje dallandıktan sonra değişiklik birleştirme ve kütüphane güncellemeleri bakım yükü olarak kalıyor
newt, mevcut bileşenleri görüş sahibi bir yaklaşımla bir araya getiren bir web araç seti olmayı hedefliyor; amaç, küçük web uygulamalarını günler yerine dakikalar içinde başlatabilmek
Rust web geliştirmede eksik olan entegre başlangıç noktası
- Rust ile küçük web projeleri oluştururken bile Django veya benzeri framework’lere kıyasla çok daha fazla ilk bağlantı işi gerekiyor
- Rust topluluğundaki yaygın yaklaşım, gerekli parçaları doğrudan kendinizin birleştirmesine daha yakın
- Are We Web Yet? de Rust web geliştirmede genellikle şeylerin elle bağlanması gerektiğini, başlarken ek kurulum işi beklenmesi gerektiğini söylüyor
- Bu ek iş, sadece “biraz daha fazla” düzeyinde değil; projeyi gerçekten başlatmadan önce ele alınması gereken pek çok kalem var
- Entegre bir web framework’ü olsaydı, insanları web uygulamaları için Rust kullanmaya ikna etmek daha kolay olurdu
- Rust’ın avantajları olarak tip sistemi, performans ve derleme süresinde verilen kahve molaları anılıyor
Neredeyse her web uygulamasının ihtiyaç duyduğu temel bileşenler
-
Yönlendirme/handler’lar
- Gelen isteklerin uygun handler’a yönlendirilmesi gerekir
- Yol parametreleri işlenmeli; tip bilgisi de varsa daha iyi olur
- Sorgu parametreleri ve form işleme de faydalıdır
-
Şablonlar
- HTML üretilmesi gerekir; bazı durumlarda JSON veya XML de üretilir
- Koşullar, match/switch ve döngüler gibi temel mantık yapılarına ihtiyaç vardır
-
Statik dosya sunumu
- CSS gibi varlıklar sunulmalıdır
- Bu iş ayrı bir sunucuda da yapılabilir, ancak yerel geliştirme ve küçük ölçekli dağıtımlarda aynı web sunucusuna dahil olması kullanışlıdır
-
Giriş
- Uygulamalar genellikle çok kullanıcılıdır ya da açık ağlarda dağıtılır; bu yüzden giriş özelliği neredeyse her zaman gerekir
- Her seferinde bunu elle bağlamak zahmetli olduğundan, en baştan kolay kullanılabilir olmalıdır
- Özelleştirme ve devre dışı bırakma seçenekleri de olmalıdır
-
Yetkilendirme
- Birden fazla kullanıcılı sistemlerde erişilebilen veri veya roller farklıdır
- Yalnızca
check(user, object, action)deseniyle bile epey yol alınabilir
-
Veritabanı arayüzü
- Uygulama verilerini saklamanın bir yolu gerekir
- ORM’e yakın bir yaklaşım faydalı olabilir, ama daha hafif bir yöntem de mümkündür
- Giriş, yetkilendirme ve yönetim araçlarında kullanıldığı için temel bir yapı taşıdır
-
Yönetim araçları
- Uygulamayı yerelde ya da prodüksiyonda yapılandırırken en az bir kullanıcıyı veya bazı verileri bootstrap etmek gerekir
- Daha akıcı bir deneyim için bazı ortak yönetim işleri gömülü olmalıdır
-
WebSockets
- Bağlı kullanıcılara veriyi daha gerçek zamanlıya yakın şekilde iten özellikler geliştirilebilir
-
Hot reloading
- Kod veya şablon değişiklikleri mümkün olduğunca hızlı yansıtılmalıdır; bu yüzden geliştirici deneyimi açısından çok önemlidir
Uzun ömürlü projeler için gereken tamamlayıcı özellikler
-
Arka plan işleri
- Zamanlanarak çalışması gereken özellikler ortaya çıkar; tutarlı bir yol olması geliştirmeyi kolaylaştırır
-
İzleme/gözlemlenebilirlik
- En küçük ve en önemsiz sistemler dışında gereklidir
- Gerçekten acil ihtiyaç hâline geldiği anda büyük fayda sağlar
-
Önbellekleme
- Uygulama biçimi çoktur ve hepsi karmaşıklığı artırır; ayrıca daha hızlı olup olmayacağı duruma göre değişir
- Framework düzeyinde bir yaklaşım iyi olur, ama kullanıcı da bunu kendisi ele alabilir
-
E-posta ve bildirimler
- Giriş özelliği varsa, parola sıfırlama nedeniyle e-posta işlevi fiilen gerekli olabilir
- Diğer bildirim türleri ise ihtiyaç duyulduğunda sonradan eklenebilir
-
Dağıtım araçları
- Belirli bir yere dağıtım için tutarlı bir yol olması faydalıdır
- Seçilen host üzerinde kullanılabilecek otomatik oluşturulmuş bir Dockerfile bile yararlıdır
-
CSS/JS bundling
- Web aracının CSS ve JS’yi tanıyıp doğal biçimde dahil edebilmesi iyi olur
- Bunun mutlaka entegre edilmesi gerekip gerekmediği ise belirsizdir
Mevcut Rust web ekosisteminin bıraktığı boşluklar
- Rust’ta halihazırda çok sayıda web geliştirme aracı var, ancak istenen entegre deneyimi hedefleyen bir araç yok
-
Minimal web framework’leri
- actix-web ve axum, Flask veya Sinatra gibi küçük framework’lere daha yakındır
- Rust tip sisteminden yararlanarak iyi bir web geliştirme deneyimi sunarlar, ancak handler’ların ötesinde neredeyse hiç ek özellik sağlamazlar
- Çoğu proje bu minimal framework’lerle yapılabilir, ancak gerekli işlevleri her seferinde elle bağlamak zahmetlidir
-
SPA framework’leri
- Dioxus, Leptos ve Yew; Rust’ı backend ve frontend’de birlikte kullanma ve frontend render için WebAssembly kullanma alanını dolduruyor
- Yew ile digital vigil yapmak keyifliydi, ancak bunu gerçek prodüksiyon ortamında kullanmak isteyip istemediğim net değil
- Bu framework’ler de kendi amaçları için harika olsa da hâlâ çok sayıda bağlantı işi gerektiriyor
-
Ayrı kütüphane kombinasyonları
- Şablon, giriş, yetkilendirme ve WebSocket kütüphaneleri bolca var
- Bazı projeler ve örnekler birkaç bileşeni entegre ediyor, ancak kullandığınız tüm parçaları birleştiren bir şeyi bulmak zor
- Hızlı hareket eden bir ekosistem olduğu için bazı örnekler güncelliğini yitirmiş olabilir
- “Sadece bağlamak”, sonuçta her kütüphanenin nasıl çalıştığını araştırıp yeterince anlamayı gerektiren bir işe dönüşüyor
Başlangıç şablonlarının çözemediği bakım sorunu
- Mevcut yaklaşım genellikle actix-web veya axum gibi temel bir framework seçip, gereken parçaları bulup eklemek ve bunları elle bağlamak şeklinde ilerliyor
- Başlangıç şablonları ilk acıyı azaltabilir, ancak bakım yükü ortada kalır
- Kütüphaneleri güncel tutmak gerekir
- Geriye dönük uyumluluğu bozan değişikliklere de uyum sağlanmalıdır
- Proje şablondan uzaklaştığında, şablon değişikliklerini yeniden birleştirmek zorlaşır
- Birden fazla proje yürütüyorsanız, tek bir framework’ü güncellemek yerine
nadet özelleştirilmiş framework’ü ayrı ayrı güncellemeniz gerekir - Her şeyi sahiplenen bir web framework’ünün sürümler arası yükseltme rehberi sunması daha iyidir
- Geriye dönük uyumluluğu bozan değişiklikler olabilir, ama bunlar belgelenebilir
- Birbirleriyle entegre olacaklarını bilmeyen iki bileşenin etkileşim değişikliklerinden kaynaklanan sorunlar azaltılabilir
newt’in hedeflediği web araç seti
- İdeal bir Rust web framework’ü, yukarıda sıralanan özelliklerin yanı sıra iyi dokümantasyon, değişiklik kayıtları, dikkatli sürüm yönetimi, uyumluluğu bozan değişikliklerin ele alınışı ve bir topluluk da sunmalıdır
- Şu anda böyle bir araç yok; başka birinin bunu yapıp yapmadığı da net değil
- Üzerinde çalışılan araç, bir framework’ten çok mevcut yapı taşlarını görüş sahibi bir yaklaşımla bir araya getiren bir web araç setine daha yakın
- Bu araç setinin adı nicole's web toolkit, kısaca
newt- public repository adresinde açık olarak bulunuyor
- Henüz kullanılabilecek durumda değil ve en güncel değişiklikler de daha push edilmedi
- Katkı kabul etmeye de henüz hazır değil
newt’in amacı, yeni küçük bir web uygulaması oluştururken günlerce bağlantı işi yapmak yerine, birkaç dakika içinde gerçek proje işine başlanabilmesini sağlamak- Bazı bileşenlerin gerektiğinde en baştan yazılması da planlanıyor
- Bu, daha kolay olabilir ya da daha tutarlı bir bütün sağlayabilir
- Rust ekosisteminin böyle birden fazla araç setine sahip olduğu sağlıklı bir duruma ihtiyaç var; başka araçların da ortaya çıkması umuluyor
1 yorum
Hacker News yorumları
Rocket’ın (https://rocket.rs/) yazarın sıraladığı framework’ler arasında olmamasına şaşırdım.
Kendim kullanmadım; daha az kural koyan axum/actix-web’i tercih ediyorum ama anladığım kadarıyla Rocket’ın hedefi, yazarın istediği piller dahil framework fikrine çok daha yakın ve zaten epey eski bir proje.
Çok uzun süre derlemek için nightly Rust gerektiriyordu ve framework’ü üretim ortamında kullanmak isteyenler için bu ciddi bir eleme sebebiydi.
Ayrıca yaklaşık 2 yıl boyunca 0.5.0 sürüm adayı durumunda takılı kaldı; en güncel kararlı sürüm de diğer Rust web framework’lerinin oldukça gerisindeydi. nightly gerekiyordu ve henüz async desteği de yoktu.
0.5 eşiği aşıldığı için şimdi daha iyi olabilir ama Rocket’ın geliştirme geçmişi, Axum gibi alternatiflerle kıyaslandığında kullanma konusunda tereddüt ettiriyor.
Bir tane var aslında: Poem[1]
Yazar Flask’tan bahsediyor ama “ihtiyaç duyulanlar” bölümüne bakınca Flask’ın da bu ihtiyacı karşıladığını söylemek zor. Django’dan gerçekten hoşlanmıyorum ama bu tür gereksinimler için yazarın tarifine en yakın şeyin Django olduğunu düşünüyorum.
Bu açıdan Poem de iyi bir aday değil. Genel olarak Poem, FastAPI’ye oldukça benziyor; bu da daha çok bir övgü. Beş altı Rust web framework’ü kullandım ve çoğunda ilk kurulumda bolca boilerplate ile uğraşmak gerekiyor. Hızlı sonuç almak istiyorsanız bu bir sorun; Poem bu noktada iyi oturuyor.
actix’in performansı oldukça iyi ama 30 ms altı yanıt hedeflemiyorsanız baştan actix’e bakmak için pek sebep yok. Pydantic benzeri bir şeye ihtiyacınız varsa bunu bir ölçüde yapan crate de var: https://crates.io/crates/poem-openapi
[1] https://github.com/poem-web/poem
Kilit nokta bunun bir “framework” olması.
F# da denemeye değer.
İstediğiniz tip sistemi oyunlarının neredeyse hepsi var; gerekli araçlar ve kolaylıklar da mevcut. Büyük dezavantajı, async işleme ve bellek yönetiminin Rust kadar zamanınızı emmemesi; dolayısıyla gerçekten iş gereksinimlerini çözme riskiniz var.
Yine de Microsoft’la uğraşma sürecinin bir yerleri o boşluğu doldurabilir gibi.
OCaml veya Haskell ile kıyaslayınca nasıl?
Popüler olmayabilecek bir düşünce: Rust bir sistem dili ve Rust ile web işi yapmak emek israfı.
Bu kullanım için çok daha iyi diller ve ekosistemler var.
Java’da olduğu gibi Rust’ta da bağlantı havuzu paylaşımı için dependency injection yapabilirsiniz; thread tabanlı arka plan işleri de çok kolay yazılabilir.
Google yakın tarihli bir sunumunda, Rust geliştiricilerinin Go geliştiricilerinden daha az verimli ya da daha az üretken olmadığını ölçtüklerini söyledi [1].
Rust harika bir dil ve onu yalnızca sistem programlamayla sınırlamak için hiçbir gerekçe yok. Çok daha fazlasını yapabilir.
[1] https://www.ardanlabs.com/news/2024/rust-at-google/
Hafif; C/C++ ve düşük seviyeli kodu kolay ve hızlı çağırmayı sağlıyor; ağ tarafında da çok fazla kontrol veriyor. PHP gibi uygulamaya özel dilleri ya da nginx/apache yapılandırma dosyalarını öğrenmeye gerek kalmadan, neredeyse her şeyi genel amaçlı ve sezgisel bir şekilde yapabiliyorsunuz.
libmicrohttpd gibi şeylerin bir Rust alternatifi olsa iyi olurdu; varsa muhtemelen kullanırım.
Gömülü programlama ile web programlamanın kesişimi için de aynı şey geçerli.
Yine de Django, .Net, Go gibi seçenekler mümkünse Rust çoğu durumda muhtemelen kötü bir tercih olur.
Statik olarak derlenen bir web framework’ü, Rails, Django, Flask gibi şeylere kıyasla kolayca 1/10 ila 1/100 kadar bellek/CPU kullanabilir.
Python’da Django, C#’ta ASP .NET Core, Ruby’de Rails var.
Rust’ı web geliştirmede gerçekten büyütmek istiyorsanız tam özellikli bir çözüm üretmeniz gerekir.
Rocket muhtemelen en yakını olabilir ama yukarıda sayılan framework’ler kadar piller dahil değil.
Yazarın aradığı şey ASP.NET Core’un Rust versiyonu ve bunda bir sorun yok.
Seçenekleri ve parçaları birleştirmeyi sevenler var; ama birçok ortamda seçimlerin sizin yerinize özenle belirlenmiş olması çok daha üretken kılar.
“Ya başka X istersem? Y% daha iyi olabilir!” türü tepkiler yaygın, ama entegrasyonun başlı başına çok büyük değer sunduğunu kaçırıyorlar. Tek tek kütüphaneler ayrı ayrı bakıldığında en iyisi olabilir; fakat birbirleriyle pürüzsüz uyum sağlamazlarsa bir çöp yığınına dönüşebilirler.
ASP.NET 8 ile programlamayı sevmemin nedeni de template sisteminin kimlik doğrulama, injection, routing vb. ile iyi çalışıp çalışmayacağını hiç düşünmek zorunda kalmamam.
loco-rs, poem, rocket’tan bahsedilmemiş mi? Zaten piller dahil deneyimi hedefleyen epey proje var.
Bu projeleri leptos gibi framework’lerden ayıran şey, yönlendiren bir CLI’a sahip olmaları. Symfony’de sevdiğim şey de bu; benim “tembel” kısmı dediğim şey de orada.
https://shuttle.rs var
Yalnızca bir framework değil, çevresindeki web boilerplate’ini de oluşturan bir araç; bu yüzden benim ölçütlerime göre yeterince tembel bir yöntem
Bu yazı birden fazla farklı noktayı aynı anda ele alıyor; idealde her biri ayrı ayrı incelenmeli
Pattern matching varsa router şart değildir. URL’yi parçalara ayırıp statik/dinamik değişkenleri gerektiği gibi eşleştirmek yeterli
Kimlik doğrulama, hangi dilde olursa olsun genelde ya elde yazılır ya da Firebase/Auth0 gibi SaaS’lar kullanılır; bu yüzden mutlaka dilin veya framework’ün sorunu değildir
CSS/JS araçları, Dominator gibi birçok Rust frontend framework’üne pek uymaz. Dominator JS ile değil Rust ile yazılmıştır; sinyallere stil bağlayıp gerçek zamanlı değişmelerini sağlamak gibi kendine özgü bir stil yaklaşımı vardır
Yazarın ne demek istediğini anlıyorum. Gerçekten de yazıdaki birçok maddeyi çözmek için defalarca araştırıp dolaştım ve bu acı vericiydi. Örneğin https://github.com/dakom/dominator-workers-fluent-auth, Cloudflare Workers framework’ü üzerinde burada geçen işlerin çoğunu hallediyor ve ek bir istek olan Fluent tabanlı yerelleştirmeyi de ekliyor
Her şeyi yapan pilleri dahil tam kapsamlı bir framework olsa güzel olurdu; ancak birçok gerçek proje bu tür kuralcı kararları değiştirmek ve kendi uygulamasını yazmak isteyecektir. Rust, frontend web tarafında da yeterince olgun ve nereye bakacağını bilirsen wasm-bindgen vb. ile her şeyi halledebilirsin
Web framework’leri URL yönlendirmeleri, sondaki eğik çizgi işleme, büyük/küçük harfe duyarlı URL yönetimi, karmaşık regex eşleştirme gibi çok daha fazlasını sağlar
“Kimlik doğrulama, hangi dilde olursa olsun genelde elde yazılır ya da SaaS kullanılır” ifadesi yanlış. Django, Laravel, Rails ve pilleri dahil dillerde kimlik doğrulama yönetimi çok iyidir. Şahsen kuruluşların %90’ında kimlik doğrulamayı dış sağlayıcılara bırakmanın çok büyük bir hata olduğunu düşünüyorum
Deneyimli bir web geliştiricisinin gereksiz karmaşıklıkla uğraşmadan bir günde 10 temel CRUD’ı ayağa kaldırabilmesi, küçük işletmeler için gerçekten büyük bir avantajdır
Bu yazı Rust yerine C++’a odaklansaydı, genel olarak aynı şeyler geçerli olur muydu?
Giriş eşiği yüksek bir sistem dili; derleme süreleri de var ve yaygın olarak kullanılmaya başlamasının üzerinden 10 yıl bile geçmemiş bir dilin erişilebilirlikte Rails gibileriyle rekabet etmesini beklemek gerçekçi değil