Rwf - Rust web framework'ü

 (github.com/levkk)
3 puan yazan GN⁺ 2024-10-23 | 1 yorum | WhatsApp'ta paylaş
  • Rwf, Rust ile web uygulamaları oluşturmak için kapsamlı bir framework'tür ve klasik MVC desenini temel alarak hızlı ve güvenli web uygulamaları kurmak için gereken özellikleri varsayılan olarak sunar
  • Temel özellikler arasında HTTP sunucusu, PostgreSQL sorguları için ORM, dinamik şablonlar, kimlik doğrulama ve kullanıcı oturumları, middleware, arka plan işleri ve zamanlanmış işler, veritabanı migration'ları yer alır
  • JSON serileştirmeyi destekleyen yerleşik REST framework'ü, WebSockets, statik dosya hosting'i, ortama göre ayarlar, logging ve metrikler, CLI da sunar
  • Hotwired Turbo ile sıkı entegrasyon sayesinde backend odaklı SPA'lar oluşturabilir; Django/Flask migration'ları için WSGI sunucusu ve Rails migration'ları için Rack sunucusu sağlar
  • Şu anda beta aşamasında olup erken benimseyenler aradığını; çoğu özelliğin iyi durumda ve dokümantasyonun kullanılabilir seviyede olduğunu belirtiyor

Rust için MVC web framework'ü

  • Rwf, Rust ile web uygulamaları geliştirmek için kapsamlı bir framework'tür
  • Klasik MVC(model-view-controller) deseniyle yazılmıştır
  • Hızlı ve güvenli web uygulamaları oluşturmayı kolaylaştırmak için gereken özellikleri varsayılan olarak içermeyi hedefler
  • Dokümantasyon resmi dokümantasyon üzerinden sunulur

Sunulan özellikler

  • Sunucu ve istek işleme
  • Veri ve uygulama yapısı
    • PostgreSQL sorgularını kolayca oluşturmak için kullanıcı dostu bir ORM sağlar
    • Veritabanı migration'larını destekler
    • Dynamic templates sağlar
    • Authentication ve yerleşik kullanıcı oturumları içerir
  • API ve iş işleme
  • Operasyon ve geliştirme araçları
    • Ortama göre ayarları destekler
    • Logging ve metrikler sağlar
    • CLI içerir

Hotwired Turbo ve migration desteği

Hızlı başlangıç

  • Bir Rust binary uygulaması oluşturup rwf'yi bağımlılıklara ekleyerek kullanılır
cargo add rwf
  • Temel uygulama, controller ve route tanımlamak için rwf::prelude::* ve rwf::http::Server kullanır
use rwf::prelude::*;
use rwf::http::Server;

#[controller]
async fn index() -> Response {
    Response::new().html("Welcome to Rwf!

")
}

#[tokio::main]
async fn main() {
    Server::new(vec![
        route!("/" => index),
    ])
    .launch()
    .await
    .unwrap();
}

Örnekler ve proje durumu

  • Yaygın kullanım senaryoları examples içinde incelenebilir
  • Rwf şu anda beta aşamasındadır ve erken benimseyenler aramaktadır
  • Çoğu özelliğin iyi durumda ve dokümantasyonun kullanılabilir seviyede olduğunu belirtiyor
  • Katkılar memnuniyetle karşılanır; rehber CONTRIBUTING, kod yapısı kılavuzu ARCHITECTURE, istenen özellikler listesi ise ROADMAP içindedir

İlgili okumalar

1 yorum

 
GN⁺ 2024-10-23
Hacker News yorumları

  • Çıkışının oldukça gerçek dışı derecede iddialı hissettireceğini düşünüyorum; tebrikler. Rails ile uzun süre web MVC yaparken öğrendiğim en büyük şey, framework'ün model katmanındaki iş mantığını güçlü biçimde bastırması gerektiğiydi.
    Veri modeline Active Record'un dediği callback'leri, örneğin afterCreate gibi hook'ları koymamanın daha iyi olduğunu düşünüyorum. ORM'de henüz yok ama yol haritasındaysa, hiç olmaması daha iyi olur bence.
    Ancak bu, yalnızca service, yani iş mantığı katmanı güçlü biçimde teşvik edildiğinde düzgün çalışır. Rails uygulamalarımın çoğunda Interactor gibi gem'lerle command/service nesneleri kuruyorum.
    Sadece MVC'nin, dolayısıyla Rails'in varsayılan yapısının, service katmanının eksikliği nedeniyle üretimde çalıştırılabilir uygulamalar yazmak için ideal olmadığını düşünüyorum. Ayrıca topluluğun mevcut ORM'lerinden ya da query builder'larından neden yararlanılmadığını da merak ediyorum. Henüz tek satır Rust yazmadım ama giderek daha çok merak ediyorum.

    • Bu bakış açısının nereden geldiğini merak ediyorum. Benim düşüncem tam tersi: mümkün olduğunca çok iş mantığı modelde olmalı.
      Service'ler neredeyse tamamen modelden tetiklenen, daha karmaşık ve belirli kod parçaları olmalı bence. İnce controller, kalın model; debug, düzen ve keşfedilebilirlik açısından en iyi sonucu verdi. Çok service kullanınca deneyimime göre bolca spagetti kod oluşuyor.
      Saf nesne yönelimli bakış açısından da model, entity'yi tanımlayan temel nesnedir. User, kendisi hakkında bilmesi gereken her şeyi bilmeli ve diğer entity'lerle mesajlar üzerinden iletişim kurmalı.
      Ancak callback'ler konusunda katılıyorum. Callback'ler çok sayıda tuhaf yan etki yaratıyor ve debug etmeyi gerçekten zorlaştırıyor.
    • İş mantığı yoksa modelin ne olduğundan emin değilim. Yapıları model, prosedürleri de service diye adlandıran bir düzen istiyor gibisiniz.
      Bunu yapabilirsiniz, ama bir entity'nin hangi yollarla güncellenebileceğini akıl yürütmek epey zorlaşır. Çünkü herhangi sayıda prosedür onu güncelleyebilir ve her birinin ayrı iş kuralları olabilir. Öyle olacaksa prosedürler doğrudan veritabanına yazsın, modeli de kaldırın.
    • Modelde iş mantığı olmaması gerektiğine katılıyorum. Martin Fowler ve Robert C. Martin buna anemik domain modeli diyor; bu, geçmişteki nesne yönelimli ve pattern ağırlıklı kurumsal geliştirme tarzının tam tersi.
      Ama 20 yılı aşkın geliştirme deneyiminden sonra encapsulation'ın bir özellik değil, yük olduğu sonucuna vardım; verinin, o veri üzerinde yapılan işlemlerden ayrılması gerektiğini düşünüyorum. Buna veri odaklı tasarım ya da veri odaklı programlama deniyor ve aynı sonuca varan tek kişi ben değilim.
    • MVC'nin tek başına üretim seviyesinde uygulamalar için yetersiz olduğu oldukça büyük bir iddia. Kişisel olarak service object'lerden hoşlanmıyorum; her yere dağılıp keşfedilebilirliği bozuyorlar.
      İyi ölçeklenen başka modelleme yaklaşımları da var ve bununla ilgili birkaç yazı da mevcut. Basecamp'ten birinin yazdığı https://dev.37signals.com/vanilla-rails-is-plenty/ buna örnek.
      Tabii bu çok nesne yönelimli, ben de pek bayılmıyorum. Örneğin Elixir'in Phoenix framework'ü, ilgili işlevleri gruplamak için context kullanır; basitçe bir facade olarak görülebilir.
      Service'leri seviyorsanız kullanabilirsiniz, ama MVC'nin üretim için yeterli olmadığı sözü biraz isabetsiz bence. Ağır iş süreçlerini model callback'leriyle ele almak iyi değil; ancak veriyi doğru forma sokan küçük işler için oldukça uygun.
    • İlginç. Şirkette kendi PHP ORM'imizi yaptık; Laravel gibi açık kaynak kütüphaneleri kullanmamız yasaktı ve hook'ların çok yararlı olduğunu düşündüm.
      Özellikle programlama deneyimim hook'ları yaygın biçimde kullanan Wordpress için PHP ile başladığı için önyargılı olabilirim.
      Yaptığım şeyde SQL tanımlarına dönüştürülebilen ya da güzel biçimlendirilmiş HTML formları üretebilen tablo tanımları var. Ayrı bir controller tüm DB bağlantılarını ve CRUD işlemlerini hallediyor; gerektiğinde başka tabloları ve kısıtları kolayca çapraz referanslayabilen öncesi/sonrası hook'ları var.
      Gayet iyi çalışıyor ama mümkün olsa anında Laravel'e geçerim.

  • Bir REST framework'üyse varsayılan olarak Swagger/OpenAPI tanımı üretimi yapabilmesini beklerim. Bunun FastAPI'nin killer özelliklerinden biri olduğunu düşünüyorum.
    Ayrıca diesel.rs gibi mevcut bir ORM ile entegre olmak yerine neden kendi ORM'lerini yaptıklarını ve popüler mevcut template engine'lerden birini seçmek yerine neden kendi template dillerini yaptıklarını pek anlayamıyorum.
    Bunun dışında proje gerçekten ilginç görünüyor ve takip etmeye devam edeceğim.
    [0] https://diesel.rs/
    [1] https://crates.io/categories/template-engine

    • Birkaç yıl önce Diesel'i denemiştim; bana fazla Rust'vari gelmişti. Şemayı iki kez tanımlamak gerekiyordu; insert ve select için aynı struct'ı kullanamadığınızdan pratikte üç kez tanımlamış oluyordunuz.
      Genel olarak veritabanı tiplerini Rust tipleriyle eşleştirmeye yönelik iyi bir ilk denemeydi, ama ORM daha esnek ve kullanımı kolay olmalı. Sorgu yazmayı zorlaştırmamalı, kolaylaştırmalı :)
      Template tarafında ise kendi dilini yapmak, 30 yaş üstü nerd kulübüne giriş ritüeline yakın bir şey. Dragon Book'u okumadım ama okulda o dersi gerçekten almak isterdim. Aynı şey için her zaman birden fazla uygulama vardır; Rails'in ERB'sinin yaptığını çok yakından taklit eden bu uygulamayı kullanmak doğru hissettirdi.
    • https://github.com/poem-web/poem Swagger tanımını yerleşik olarak sunan bir Rust framework'üdür.
    • Ters yönde çalışan benzer bir framework bilen var mı merak ediyorum. Yani OpenAPI tanımını doğruluğun kaynağı olarak tutup sunucunun buna uyup uymadığını doğrulayan bir yaklaşım.
    • OpenAPI'yi sunucudan üretmenin %100 killer özellik olduğunu düşünüyorum. Biz Dropshot ile bunu iyi şekilde kullanıyoruz.
    • Ben de bir REST framework'ünün varsayılan olarak Swagger/OpenAPI tanımı üretmesini beklerim. Ancak anladığım kadarıyla bu, web API'leri kurmaya yönelik bir framework değil; HTML döndüren bir MVC framework'ü.

  • Bir SRE gözüyle https://levkk.github.io/rwf/migrating-from-python/ ilgimi çekti. Bir yandan bunu başarmış olmaları gerçekten harika, ama diğer yandan kararlılığa bakan bir SRE açısından içten içe çığlık attırıyor
    Ölçek büyüdüğünde bunu Caddy, Nginx, Traefik gibi ters proxy'lerin halletmesi gerekir

    • Ben de aynı şeyi düşündüm ama bu yaklaşımla uygulama mühendisi gidip gelmeden değişikliği yerelde test edebilir. Sonunda yine eski monolit mi mikroservis mi tartışmasına dönüyoruz
      Sağlam bir WSGI sunucusu yazmak mümkün ve iş parçacığı sayısı, vacuum, eski php-fpm'deki gibi her n istekte bir yeniden başlatma gibi ayrıntılara biraz dikkat ederseniz o kadar da zor değil. Temelde uwsgi'nin sahip olduğu seçeneklerin çoğunu uygularsanız doğru yoldasınız demektir. Rwf'yi Gunicorn çalıştırmayla karşılaştırılabilir hâle getirmek yol haritasında var
    • Yazarın, teknik okurların WSGI sunucusunun önünde ters proxy gerekliliğini ayrıca söylemeye gerek duymayacağını varsaydığını sanıyorum

  • İsim seçimi gerçekten müthiş. Arama sonuçlarının en tepesine çıkmanın bir yolu bu :P
    Ciddi konuşursak iyi yapılmış. İyi bir framework yapmak şaşırtıcı derecede büyük bir iş ve insanların tasarım alanını keşfedip yeni fikirler denediğini görmek her zaman güzel

    • Rust projeleri böyle geniş, genel ve kendini fazla öne çıkaran isimler seçme eğiliminde; açıkçası bunun büyük bir hata olduğunu düşünüyorum. Crates.io, kulağa iyi gelen isimleri kapmış terk edilmiş projelerin mezarlığı olacak
    • “Row” da güzel bir isim ve rwf'den söylemesi daha kolay olur gibi
      RustOnWeb.com da 10 dolara alınabiliyor :) Öyle laf olsun diye söyledim

  • “Rails'i düşün, Flask'ı değil” ifadesini sevdim. Statik tipli dillerde de Rails/Django gibi fikri güçlü framework'lerin daha fazla ya da daha iyi olması gerekiyor

  • İyi yapılmış. https://www.arewewebyet.org/ üzerinde yer alması için denemeye değer

    • Bu sayfada loco.rs'nin olmaması epey şaşırtıcı. Rust framework'leri arasında en çok “Rails”e benzeyen o gibi duruyor, yine de yok

  • Güzel! Üst düzey bir dille yapılmış Django/Rails demek
    Öneri olarak, async-trait artık kararlı hâle gelmiş olmalı; bu yüzden makroya artık gerek kalmayabilir. Ayrıca varsayılan olarak metrik ve izleme elde edilebilmesi için OpenTelemetry entegrasyonu eklemek iyi olur. Linux hedeflerinde jemalloc kullanmak da iyi olur

    • Teşekkürler. Standart async trait'leri kullanmayı denedim ama Rwf'nin yaygın biçimde kullandığı dinamik dispatch'i desteklemiyorlar
      tracing crate'indeki fonksiyonlara OpenTelemetry etiketleri eklemeyi planlıyorum. jemalloc, Rwf kullanan ikili uygulamaya eklenebilir; kütüphane bağımlılığı olarak koymaya gerek yok
      [1] https://blog.rust-lang.org/2023/12/21/async-fn-rpit-in-trait...
    • Linux hedeflerinde jemalloc kullanmak neden gerekli, merak ediyorum. Ya da diğer hedeflerde neden gerekmediğini

  • Rust öğrenmeye çalıştım ama başlarda bıraktım. C#, C/C++, Java, Python'dan gelince Rust tuhaf hissettirdi
    Beni zorlayan şey tuhaflığın kendisi değil, C#, Java, Python gibi dillere kıyasla bir işi bitirme hızının düşük olmasıydı
    Bu aralar ağırlıklı olarak web geliştirme yaptığım için kullanım kolaylığı ve üretkenlik en öncelikli konular. Rust throughput ve hız açısından biraz daha iyi olabilir, ama güncel web framework benchmark'larına bakınca C# ve Java da bu konuda oldukça iyi durumda
    Bunu Rust eleştirisi ya da sıfırdan bir MVC framework yapmanın büyük başarısını küçümseme olarak okumayın. Daha çok “işe uygun doğru araç” meselesi

    • Ne demek istediğini tamamen anlıyorum. Ben dâhil birçok kişi başta benzer bir deneyim yaşadı
      Öğrenme eğrisini aşmak için güçlü bir motivasyon gerekiyor. O dili kullanmak zorunda olmak, tip sistemi ve güvenlik avantajlarına çekilmek ya da kendine özgü somut bir nedenin olması gibi
      Böyle bir motivasyon yoksa bunda hiç sorun yok. Bende de başta yoktu; bu yüzden ilk öğrenme denemelerim fazla ilerlemedi. Birçok kişinin hissettiği gibi Rust'ta işleri bitirmek Java veya Python'a göre daha uzun sürüyor ve baştan daha fazla düşünmek gerekiyor. Bazı durumlarda buna değer, ama o ödünleşimi neden kabul edeceğiniz net değilse devam etmek için güçlü bir sebep yok

  • Kısa süre önce webpack JS loader'ını bırakıp 50 kat hızlı bir Rust loader kullanmaya başlayınca ben de Rust'a kapıldım. Rust'ın performans artışı etkisi büyük; şu anda en sevdiğim diller C++ ve Rust

    • Aa, webpack'i bırakıp ne kullanmaya başladığını paylaşabilir misin?

  • Backend Rust işi için sıkça adı geçen tüm adayları değerlendirdim ve küçük prototipler yaptım. Şimdilik istediğimden daha düşük seviyeli olsa da genel olarak Axum'un en iyi seçenek olduğu yönündeki kolektif sonuca istemeye istemeye katıldım
    Diğer adaylar Loco ve Rocket'tı. Loco Rails'e fazla benziyordu; Rocket'ta ise Rust'ı daha çok kullandıktan sonra makrolar gözüme batmaya başladı
    Bu framework, “pilleri dâhil ama fazla kuralcı olmayan” ölçütüme tam uyuyor gibi görünüyor. Ekosistem için güzel bir katkı

    • Actix nasıl olur? Hatırladığım kadarıyla eskiden HN'de Actix ve Axum üzerine bir tartışma vardı