Rails for Everything - Rails'in Her Şey İçin Gücü

• Rails 8, küçük ölçekli projeler ve tek kişilik geliştiriciler için son derece faydalıdır
• En yeni başlangıç kılavuzu ile üretim düzeyinde uygulamayı kolayca kurabilirsiniz
• SQLite geliştirmeleri sayesinde ek sunucusuz güçlü bir veritabanı ortamı kurulabilir
• Yerleşik olarak sunulan sürekli entegrasyon (CI) ve kimlik doğrulama oluşturucusu ile geliştirme verimliliği ve güvenlik artırılır
• Kamal ile basit dağıtım yöntemiyle hızlı ve güvenli şekilde hizmet işletilebilir

---

Genel bakış

• Rails 8 kullanım deneyimi üzerinden bakıldığında, küçük projeler veya bireysel geliştiriciler için mükemmel bir web çerçevesidir
• Hızlı kurulum, verimli dağıtım, yerleşik modüller sayesinde, rekabet eden çerçevelere göre üretkenlik açısından belirgin avantajlar öne çıkar

En İyi Başlangıç Kılavuzu

• En güncel Getting Started with Rails kılavuzu, başlangıç seviyesi bir kullanıcının bile üretim uygulaması geliştirebilmesi için düzenlenmiştir
• Ruby yükleme süreci hâlâ karmaşık olsa da, kılavuzdaki adımlar takip edildiğinde kimlik doğrulama, önbellekleme, zengin metin, sürekli entegrasyon, veritabanı gibi bileşenlerin tümü olan güçlü bir servis kurulabilir
• Sıradan bir ‘Hello World’ yerine, gerçek hizmet seviyesinde temel beceri ve özellikler sunması en büyük güçlü yanı
• Rails'e yeni başlayanlar için ideal bir başlangıç noktası olur

Tek Başına SQLite'ın Yetmesi

• SQLite temelde güçlü bir araç olmasına rağmen, uzun süre boyunca üretim için kullanımı kolayca yapılandırılamıyordu
• Eskiden ek gem kurulumu gibi ek adımlar gerekirdi; ancak Rails 8 ile ek bir işlem olmadan canlı ortamda güvenli biçimde çalıştırılabiliyor
• PostgreSQL veya ayrı bir sunucu çalıştırmak zorunda kalmadan, solid cache ile redis sunucusuna da ihtiyaç duyulmaz
• Rails ve SQLite ile yalnızca servis çalıştırmak mümkün olur ve kurulum ile işletme basitliği maliyet etkinliği en üst düzeye çıkarılır

Kolay Sürekli Entegrasyon (CI)

• İlk commitin ardından CI başarısız bildirimleri geleceği noktaya kadar, Rails 8'de ön tanımlı entegre CI ayarı sunulur
• Ek bir işlem olmadan GitHub Actions ile entegre olur ve her ay 2.000 dakikalık ücretsiz çalışma süresi alınabilir
• Tek geliştirici açısından oldukça yeterli bir zaman dilimidir

Kimlik Doğrulama Oluşturucusunun Eklenmesi

• Önceden Devise gibi kimlik doğrulama gem'leri güçlüydü ama yapılandırma karmaşıklığı nedeniyle başlangıç seviyesindekilere biraz zor görünüyordu
• Rails 8'de basit bir kimlik doğrulama oluşturucusu eklendi; konsoldan mevcut bir kullanıcı eklemekle kolayca oturum açma akışı uygulanabilir
• Üretilen kod basit ve okunabilir olduğu için yeni başlayanların anlaması kolaydır

Kamal ile Kolay ve Hızlı Dağıtım

• Dağıtım sürecini Kamal üstlenir; deploy.yml dosyasının yalnızca bir kısmını değiştirip yönergeleri takip ederek doğrudan SSL ortamında uygulama çalıştırılabilir
• GitHub Pages'e SSL bağlamaktan daha hızlı bir web uygulaması dağıtım deneyimi sunar
• Sürekli entegrasyon (CI) ve kolay dağıtım birleşimi, Rails 8'in en belirgin avantajlarından biridir
• Sadece başlangıç kılavuzunu takip etmeniz bile güncel en iyi uygulamalara uygun bir geliştirme deneyimi sağlar

Sonuç

• Rails hâlâ güçlü ve gelişen bir çerçevedir
• Bu yıl yeni bir proje planlıyorsanız, Rails 8 ile geliştirmeye başlamak denemeye değerdir

[aer0700]

Son zamanlarda SQLite yazılarını çok görüyordum, şimdi de işin bittiği nokta SQLite oldu.
Bunu bir klasiklerin geri dönüşü olarak nitelendirmeli miyiz?

[GN⁺]

Hacker News Yorumu

• Son günlerde Spring Boot, Micronaut yığınıyla uygulama geliştirip React ön yüzünü de deniyorum. Rails'in omakase (her şeyiyle gelen) yaklaşımı gerçekten çok iyi geliyor. Backend'den gelen form doğrulaması veya flash mesajı gibi basit işlevler bile framework tarafından doğrudan çözülmediği için bunları ya kendin yazman ya da üçüncü taraf araman gerekiyor. Rails, web uygulamalarının %90'ının karşılaştığı sorunları önceden çözer. Kusursuz olduğu söylenemez ama çoğu durumda varsayılanlarla yeterli olur ve gerektiğinde her zaman değiştirilebilir.
  • Spring Boot'ta form doğrulaması neredeyse hazır ve doğrudan anotasyonla yapılabiliyor.
• Rails ve Django ikisi de harika frameworkler. Python ile kritik uygulamalar bile geliştirdim. Ama büyük ölçekli bir monolith geliştirmeye geçince Go'ya geçme isteği oluyor. Go'nun tip sistemi ve eşzamanlılığı daha güçlü geliyor. Sorun şu: Go ekosistemi Rails veya Django gibi bir framework ekosistemi yaratmıyor. Go ile ağ araçları veya CLI üretmek çok iyi ama hızlıca tam yığın web uygulaması kurarken hâlâ Rails veya Django'yu seçiyorum. Bu yüzden “Rails öldü” diyenlerine katılamıyorum.
  • ogen gibi araçlarla tek bir OpenAPI belgesinden statik router, istek/yanıt doğrulaması, Prometheus izleme, OpenTelemetry izleme gibi neredeyse her şey otomatik üretiliyor. İstemci ve webhook kodu üretme de mümkün; auth için yalnızca tek bir özellik eklemek yeterli. sqlc ve SQLite'ın pragma user_version birleşimiyle tip güvenli DB kodu ve migration'lar da kolaylaşıyor. SQLite eklemek de sadece main.go'ya iki satır import eklemek kadar basit. Go'nun standart şablonlarıyla bile front-end metin işleme için yeterli, embed ile statik varlıklar da binary'e kolayca eklenebiliyor. Dağıtım da go build çalıştırıp binary taşımakla bitiyor; bu yüzden dağıtım çok basitleşiyor. Kod üretim araçlarıyla Go backend geliştirme gerçekten hızlı ve pratik oldu.
  • Ben de tam statik tipli bir stack istiyordum ama Go ya da Rust'tan çok daha net cevap ASP.NET'ti. Microsoft'un yeni ürünlerini (ör. Aspire.NET) çok öne çıkarmasına rağmen, tam tersine .NET Core (C#, ASP.NET Minimal API/MVC, EF Core) gerçekten batteries included ve güvenilir. Biraz OOP ve DI bakış açısı değişimi gerektiriyor ama deneyimli geliştiriciler için büyük problem değil.
  • Go ekosistemindeki sorun yalnızca anti-framework zihniyeti değil, aynı zamanda anti-modern özellik zihniyeti. Java, Kotlin, Scala, C#, F# gibi diller de ağ araçları veya CLI geliştirmede iyi. Bugün Java AOT de artık ticari lisans endişesi olmadan çalışıyor; .NET de Windows'a hapsolmuş değil.
  • Encore'yi öneririm. Özellikle PaaS entegrasyonunda (NextJS+Vercel kombinasyonu gibi) gerçekten güçlü. Go'nun ana prensiplerinden biraz farklı olabilir ama küçük ekipler veya tek kişilik ekipler için mükemmel bir seçim. İstersen BYOC ile doğrudan deploy edebilir ya da doğrudan stdlib ile API katmanı açabilirsin. Ön yüz için NextJS veya Remix/RR7 gerekebilir ama TypeScript istemci SDK'sının otomatik üretilmesi entegrasyonu çok kolaylaştırıyor. Encore'ın Vercel PR entegrasyonu da var; o da büyük bir avantaj.
  • Go'da Django benzeri deneyim verebilen en iyi seçenek beego; o kadar. Ama olgunluğu hâlâ Django veya Rails düzeyinde değil.
  • Şu anda Go ile yaptığım bir projede gerçekten temiz koddan memnunum. AI, framework'e geçiş engelini aşmada büyük yardım sağlıyor. Yine de müşteri odaklı servislerde rails, iç araçlar ve veri işlerinde django daha sezgisel.
  • Ruby'de Sorbet ile tip kontrolü mümkün ve Fiber ile desteklenen concurrency neredeyse olgunluk çağında. Falcon adlı yeni bir web sunucusu Fiber ile inşa ediliyor. Henüz Puma kadar olmasa da yakında gerçek kullanıma hazır olacak.
  • Stanza dilinin yazarı, Rails'e benzer güçlü bir framework için dilde de koşullara ihtiyaç olduğunu anlatan bir fikir yazmış. Go veya Java'da o tür frameworkler olmaması dilin (veya programcıların) sınırlılığıyla ilgili.
  • Go baştan beri böyle bir (Rails/Django tarzı) tam yığın framework yaklaşımını taşımadı.
  • Node/Express yerel geliştiriciler için bir pikodüzey servis olarak uygun; ASP.NET WebAPI/MVC ise benim için ideal backend.
  • goravel dev da bir kez deneyebilir.
• Rails Guides'i baştan sona izlersen, kimlik doğrulama, cacheleme, zengin metin, CI, DB dahil gerçek bir servisi doğrudan yayınlayabilirsin. Ama GitHub, Airbnb gibi büyük servisler için uygun olsa da, erken aşama start-upta Devise auth, turbo, test gibi ekstra/yerleşik işlevleri en baştan tamamını koymak tersine zaman kaybına dönüşebilir. turbo'nun sayfa yüklemeyi hızlandırma avantajı var ama Devise işlevleriyle çakışınca geliştirme süresi uzayabiliyor. Lansman öncesi fikir doğrulama aşamasındaysak, banking/sağlık uygulamaları dışında test veya CI gibi şeyleri ertelemek büyük sorun olmaz. Varsayılan yanlışı (var diye kullanalım) değil, gereksizse “şu an kullanmayacağım” diyebilmek önemli.
  • SaaS uygulaması planlıyorsan Jumpstart Pro veya Bullet Train gibi Rails'e özel şablonlarla başlamak aylarca geliştirme süresini kısaltır. Ödeme, auth gibi temel fonksiyonlar zaten var ve sonrasında genişletmesi kolay.
  • Test yaklaşımına katılmıyorum. Oldukça küçük bir uygulama bile test kodu varsa zaman kazandırır. CI de genelde sadece yirmi satırlık tek bir dosyayla biter; eski projelerden copy/paste ettim.
  • CI geliştirme hızını azaltan değil, hızlandıran bir unsur. Projeye başlangıçta mutlaka eklenmeli.
  • Flask/Express/Sinatra/Gradio/Hono gibi yerlerden Rails'e geçişin hangi noktada gerektiğini merak ediyorum.
• Son Rails sürümü eskisine göre gerçekten çok parlak görünüyor, bu beni mutlu ediyor. Rails 2.3'ten itibaren 12 yıldır farklı uygulamaların bakımıyla uğraştım ama bugün Rails bambaşka bir evrilen Pokémon gibi. Rails Upgrade Guide o kadar iyi düzenlenmişti ki büyük refactor olmadan tek seferde sorunsuzca yükseltebildim. Backward compatible değil ama değişimlerin açıkça belgelenmesi büyük avantaj. ActiveStorage ile dosya ekleme büyük gelişmiş; Webpacker geçişi biraz zordu ama Import Maps sayesinde şimdi çok daha kolay gibi.
  • 4 yıl önce, bütçesi sınırlı bir müşteri için maaşımı dahi düşürerek eski bir Rails uygulaması sürdürmeyi seçtim (Ruby 2.3 dönemi). Sonuçta upgrade ve özellik eklemenin gerçekten kolay olması beni çok memnun etti.
• Tek başıma açık kaynaklı bir Rails projesi geliştirip ayda 120 bin kişiye destek veriyorum ve yukarıdaki görüşe çok katılıyorum. Ayrıca ActiveStorage'ın attachment özelliği gerçekten çok iyi. Dağıtım için daha çok Dokku kullandım ama Kamal kullanmayı merak ediyorum. Rails ilerleme halinde ve Ruby de giderek hızlanıyor.
  • Dokku'yu seviyorsan Cloud Native Buildpacks'i denedin mi? Onunla doğrudan OCI image üretmek mümkün.
• Ruby öğrenmek için web geliştirme konusunda çok deneyimim yoktu, bildiğim şey büyük ölçüde Django oldu. İki framework'ü karşılaştırınca farklar neymiş merak ediyorum.
  • İki ekosistemde de uzun tecrübem var (sonra Rails'i az yaptım). Django python, Rails ise ruby/gem ile bağlı olduğu için ekosistem etkisi önemli. Django admin CMS, Rails'ten belirgin biçimde güçlü ve birçok organizasyon iç CMS'lerini tamamen django'ya dayandırıyor. Rails'in muazzam bir scaffolding CLI'ı var, CRUD işlevlerini inşa etmede gerçekten hızlı. Rails, Django'dan daha yüksek bir soyutlama seviyesinde, çünkü yapı ve mimariyi Rails çoğunlukla üstleniyor; Django'da ise çok daha çok seçim var. Rails, DRY ve kod tekrarını azaltmaya daha takıntılı. Pythonic sezgiyi önemseyenler Rails'in sihirli yönünü ağır bulabiliyor; Rails ekibi ise Python'un tekrarlarını kaba bulabilir. Temelde ikisi de farklı stil.
  • Ben web uygulaması (son kullanıcı odaklı ürün) yapacak olsam rails'i önce seçerdim. Scaffolding ve pazara çıkışa kadar her şey daha kolay gibi (gerçekte çok büyük bir servis deneyimim yok). İç araçlar, veri işi ve coğrafi sistemlerde ise python/django daha iyi.
  • En büyük fark python vs ruby. Python ekosistemi çok büyük ve Django'da auth ve yerleşik admin var.
  • Test ortamında Rails deneyiminin daha iyi olduğunu düşünüyorum. Rails hem CI ayarını hem test kodu otomatik üretimini birlikte veriyor.
  • Django Admin deneyime göre Ruby tarafındaki alternatife göre çok daha esnek ve daha kolay kullanılır. Ancak test ve routing Rails'de daha iyi ve konvansiyonlar daha güçlü. Bireysel tercihim ActiveRecord+arel'in Django ORM'den daha çok hoşuma gitmesi. (Kişisel olarak Ruby kodu yazmak Python'dan daha zevkli geliyor)
  • Ruby öğrenmek zor değil ve rails, Django'dan çok daha fazla yapı ve konvensiyon önceden sağlıyor.
• Pek çok kişi Rails'e neredeyse aşk gibi bir bağlılık duyuyor, ben o düzeye ulaşamadığımdan bazen kıskanıyorum. Her dil/framework'da hayran kitlesi var ama Rails'te ısı biraz daha özel.
  • Rails'in convention'larına karşı rahatsızım çok şey var ama JavaScript backend'de benzer verimliliği düşürmeye/indirmeye çalışırsan neredeyse imkansız. Tam tersine, Rails kodunu devraldığımda da çoğunlukla Rails'in çekirdek fonksiyonlarını (ör. Active Job) gereksiz nedenlerle yeniden implemente etmiş örnekler gördüm. Konvansiyona uymak her zaman daha verimli.
• SQLite'yi production'da kullanınca migration yüzünden sonunda çile çekiyorsun. Örneğin mevcut bir kolona NOT NULL kısıtı eklemek için tablonun tamamını geçici bir tabloyla yeniden yazmak zorundasın.
  • SQLite'te ADD CONSTRAINT da yok, PL dili veya basit stored proc da desteklenmediği için sürekli host (ana) dilde roundtrip yapman gerekir, statik tipli dillerde özellikle hantal.
  • Postgres bence en iyi, kolay kolay bırakmayacağım. Yine de Rails'te sqlite3'ün birinci sınıf bir seçim olarak yer alması olumlu bir gelişme.
  • Rails'in default önerisi, sqlite'nin redis yerine geçeceği de olabilir ama pratikte sadece küçük servis başlangıçları için geçerli. Sonra başka DB'ye geçmeyi düşünüyorsan sqlite ile başlamanı önermem. Migration her zaman acı verici.
  • Rails'te çoğu şeyi ActiveRecord validation ile yönetebilirsin ama temel kısıtların yansıtılmasında sınırlılık var.
• Ruby kurulumu biraz karmaşık kalmış. 15 yıl sonra jekyll blog kurarken gem kullanımıyla baya zorlandım. Bu da benim hatamdı ama daha kolay hale getirilebilse iyi olurdu. Yine de Ruby'ye geri dönmek için bir sebep oldu.
  • Kurulum herkes için kolay olmalı diye düşünüyorum. Jekyll'i çabuk öğrendim çünkü ortamımda zaten Ruby ve RubyGems vardı.
• Sadece sqlite kullanacaksan litestack de bir kez bakılabilir. Kendi kullanımımda yok ama kişisel bir projeyi postgres'tan litestack'e taşıma planım var. Benchmark performansı gerçekten çok etkileyici.
  • Rails 8'de sqlite çok güçlendiği için, gerçekten litestack gerekli mi merak ediyorum. Hangi farklar var merak ediyorum