Litestar’a Bir Göz Atmakta Fayda Var

• Litestar, Python asenkron web framework’leri arasında daha az bilinen bir cevher
• Hızlı ölçeklenebilirlik ve esnek mimarisi sayesinde farklı projelere kolayca uygulanabiliyor
• Pydantic gibi belirli kütüphanelere bağımlı olmayan veri modelleme sunuyor
• SQLAlchemy entegrasyonu çok güçlü; veritabanı bağlantısı ve yönetiminde avantaj sağlıyor
• Kullanışlı kimlik doğrulama, cache, logging, monitoring gibi yerleşik özellikleri ile doğrudan gerçek projelerde kullanılabiliyor

---

Litestar Genel Bakış

• Son birkaç yılda async-first, type hint tabanlı Python web framework’leri öne çıkarken, bunlardan biri olan Litestar seçilerek kullanım deneyimi kazanıldı
• Gerçekten birden fazla projede Litestar ana framework olarak benimsendikçe, bu seçime duyulan güven artmaya devam etti
• Python web geliştiricileri arasında bile Litestar’ı bilmeyen çok kişi olduğu için, bu yazı üzerinden başlıca avantajları ve öne çıkan özellikleri tanıtılıyor

Örnekler ve framework karşılaştırması

• Litestar ile çok basit bir tek dosyalı web uygulaması bile kolayca yazılabiliyor

  • route decorator, uygulama nesnesine bağlı olmayan bağımsız bir fonksiyon
  • Örnek kodda /greet?name=Bob adresine gidildiğinde “Hi, Bob!” döndürülüyor
  • Zorunlu parametre eksik olduğunda otomatik olarak 400 yanıtı veriliyor

• Flask, FastAPI gibi mevcut Python mikroframework’lerinden farklı olarak Litestar, farklı ölçeklerdeki projelerde doğal şekilde genişleyebilen yapısal özelliklere sahip

  • Flask veya FastAPI yaklaşımında routing decorator’ları uygulama nesnesine bağlı olduğundan, çok dosyalı ayrımda döngüsel import sorunu ortaya çıkabiliyor
  • Genellikle alt route registry’leri (Flask/Quart için blueprint, FastAPI için APIRouter vb.) kullanmak gerektiğinden giriş eşiği yükseliyor veya yapısal değişiklik ihtiyacı doğuyor
  • Buna karşılık Litestar’da decorator bağımsız bir fonksiyon olduğu için, tek dosyalı bir uygulamadan büyük ve dağıtık bir yapıya geçiş oldukça sade kalıyor

• Litestar’ın temel mimarisi ve dokümantasyon yaklaşımı sayesinde, router ve özellik paketleri kavramları en baştan tanıtılabiliyor; bu da karmaşık API yapılarında tutarlılığı korumayı kolaylaştırıyor

  • Dependency injection, yetkilendirme, yol bazlı config paylaşımı gibi konularda composability güçlü bir taraf
  • Aynı route birden fazla kez kaydedilerek ortama göre kimlik doğrulama veya dependency uygulamak mümkün

Pydantic bağımlılığından uzak modelleme

• FastAPI gibi framework’ler veriyi Pydantic’e güçlü biçimde bağlıyor

  • Pydantic, tip tabanlı veri doğrulama ve serileştirmede güçlü; ancak ORM (SQLAlchemy) ile doğrudan entegrasyonu zor
  • Gerçek projelerde SQLAlchemy modeli ile Pydantic modelini ayrı ayrı yazmak gerekmesi zahmet yaratıyor

• Litestar, yalnızca Pydantic değil dataclasses, msgspec, attrs, SQLAlchemy model gibi çok çeşitli tipleri genel amaçlı olarak destekliyor

  • serialization plugin protocol ile genişletilebilirlik sunuyor
  • DTO (veri aktarım nesnesi) otomatik çıkarma özelliği sayesinde yalnızca kaynak veri sınıfı değiştirildiğinde DTO da otomatik güncelleniyor
  • Bazı alanları hariç tutma, dahil etme, isim eşleme, kısmi güncelleme DTO’ları gibi yapılar da kolayca tanımlanabiliyor
  • Böylece model alanlarını tekrar tekrar tanımlama ve elle senkronizasyon sırasında yapılan sık hatalar önlenebiliyor

SQLAlchemy ile entegrasyon ve Advanced Alchemy tanıtımı

• SQLAlchemy ORM, fiilen Python veritabanı entegrasyonunun standardı

  • Litestar; SQLAlchemy şemasının otomatik serileştirilmesi, DTO otomasyonu, oturum yönetimi eklentisi ve birleşik eklentiler gibi alanlarda son derece güçlü bir entegrasyon sunuyor

• Advanced Alchemy kütüphanesi (Litestar ekibi tarafından bakımı yapılıyor) ile SQLAlchemy yetenekleri daha da genişliyor

  • Veritabanından bağımsız büyük PK, otomatik timestamp, UUID anahtarları, JSON tipi, Alembic migration entegrasyonu, Seed/Export gibi çeşitli kalite iyileştirme özellikleri sunuluyor
  • Özellikle dikkat çeken özellik, repository ve service layer soyutlamalarını desteklemesi; böylece CRUD ve pagination gibi birçok depo işlevi otomatik sağlanıyor
  • Django’dan farklı olarak yapısal rehberliği daha zayıf framework’lerde, repository/service layer kullanımını teşvik edecek bir organizasyon biçimi sunuyor

Diğer özellikler ve yerleşik destekler

• Litestar; kimlik doğrulama sistemi (guard fonksiyonu, middleware), cache (stores), logging, standartlaştırılmış problem yanıtları, Prometheus/OpenTelemetry tabanlı metrikler, htmx desteği gibi özellikleri de framework içinde sunuyor
• Diğer mikroframework’lerin aksine, bazı özellikleri uygularken ayrı harici kütüphaneler aramaya veya özel glue code yazmaya gerek kalmıyor
• “Mikroframework” sadeliğini korurken, genişleme veya ek özellik ihtiyacında gerekenleri doğrudan kullanıma açıyor
• Django/Flask alternatifi olmaktan çok, Java Spring Boot gibi başka dillerdeki framework’lerin güçlü yönlerini (başlangıç yapısı + kullanım kolaylığı vb.) Pythonic bir yaklaşımla birleştirme fikrine dayanıyor
• Genel olarak gerçek dünya Python web geliştirmesinde yüksek üretkenlik ve yapısal avantajlar sunan bir seçenek

Sonuç

• Litestar; asenkron yapı, tip tabanlı yaklaşım, esnek ölçeklenebilirlik, sıkı olmayan veri modelleme, güçlü ORM ve yerleşik özellikleri sayesinde Python web geliştiricilerinin mutlaka en az bir kez değerlendirmesi gereken bir framework olarak öne çıkıyor
• Gerçek projelerde tekrar tekrar kullanılması sonucunda, startup’lar dahil çeşitli proje ortamlarında yüksek üretkenlik ve bakım kolaylığı sağladığı görüldü
• Geliştiricilerin bir sonraki Python web projesini planlarken Litestar’ı seçeneklerden biri olarak değerlendirmesi umuluyor

[minhoryang]

Python’daki "circular import sorunu" için zaten net bir çözüm yok mu? Bunu büyük bir sorun olarak görmek biraz zorlama gibi geliyor bana.

[GN⁺]

Hacker News görüşü

• Son 1 yıldır FastAPI ile büyük ölçekli bir backend projesi geliştiriyorum. Resmî öğretici tarzını takip ederek başladım ama FastAPI’nin resmî şablonunun tüm CRUD işlemlerini tek dosyaya koymayı önermesi ve bağımlılık yönetimi yaklaşımı rahatsız ediciydi. SQLModel kullanırken de polimorfik model desteğinin olmaması gibi çeşitli sınırlamalarla karşılaştım; toplulukta iyileştirme PR’ları açılsa bile aylarca inceleme bile almaması, bakımının gerçekten sürüp sürmediğini sorgulatıyordu. Dokümantasyonda da gerçek kullanım için yeterli referans yoktu; sonunda kaynak kodu bile kazmak zorunda kaldım. Hızlıca CRUD çıkarmak için fena değil ama karmaşık sistemler kurmak için framework üstüne bir framework daha koymak gibi hissettiriyor; bu yüzden önermeyi düşünmüyorum. Yarından itibaren Litestar’a migrate etmeyi planlıyorum
  • FastAPI’nin pratikte büyük uygulamalarda nasıl kullanıldığını öğrenmek için polarsource/polar reposunun server koduna bakmak faydalı olabilir. Kimlik doğrulama, testler ve gerçek ölçeklenme örnekleri iyi toplanmış; ben de bu repodaki uygulama tarzını takip ederek öğrenmeyi düşünüyorum
  • API odaklı uygulama tasarımına yeni giriyorum ve bu yazı sayesinde daha önce aklıma gelmeyen birçok mimari ve araç noktasını öğrendim. Ben de Litestar’ı denemeyi düşünüyorum. Faydalı görüşler ve yazı için teşekkürler
  • FastAPI’nin resmî öğreticisinde SQLModel’in aşırı öne çıkarıldığı fikrine katılmıyorum. Açılış sayfasında SQLModel’den hiç söz edilmiyor; yalnızca ilişkisel veritabanı bağlantısını anlatan sayfada ele alınıyor. Öğreticide belirli bir ORM kullanılması doğal bir tercih ve SQLModel uymuyorsa kullanıcının başka bir seçenek seçmesi gerekir diye düşünüyorum. Ben de öğreticiyi gördükten sonra plain SQLAlchemy kullanmaya karar verdim
  • Litestar dokümanlarını okuyunca olay sisteminin de yerleşik olduğunu gördüm. FastAPI’de haftalar harcayıp ayrıca kurduğum bir özellikti; Litestar’da en baştan hazır geliyor
  • Litestar’ın da bazı sınırlamaları yok mudur diye düşünüyorum. Topluluk, dokümantasyon ve tartışmalar FastAPI’den daha azken, yine de karmaşık uygulamalar için daha uygun olduğunu düşünüp düşünmediğinizi merak ediyorum
• Litestar, API backend kurmak için çok güçlü. Bizzat kullanıyorum ve güçlü şekilde tavsiye edecek kadar memnunum. Advanced Alchemy de giderek daha iyi oluyor. Eski usul server-side template rendering siteleri de Litestar ile rahatça yapılabilir ve HTMX için eklenti de yerleşik geliyor. Ancak API endpoint tasarımı için olan kalıplar, form doğrulama ve yönlendirme gibi geleneksel server-rendered endpoint’lerde biraz garip durabiliyor. Litestar’ın kendi içinde gerçek anlamda form işleme özelliği olmadığından, form alanı bazında hataları düzgün ele almak zor. @post("/route", exception_handlers={...}) kullanan yaklaşım biraz tuhaf geliyor. İleride daha iyi yerleşik araçlar ve geliştirici deneyimi iyileştirmeleri gelmesini umuyorum
  • Litestar’ı bizzat kullanmadım ama form tarafındaki her şeyi çözen kendi dekoratörünüz olan @postform gibi bir şey yazmak mümkün olmaz mı diye düşünüyorum
• Litestar bir Python web framework’ü. Merak edenler için önce bunu paylaşayım
  • Bu sayede zaman kazandığını söyleyenler de vardı
• 1 yılı aşkın süredir Litestar ile hem JSON hem de şablon tabanlı HTML servis ediyorum. FastAPI’den daha hızlı, hafif ama kimlik doğrulama ve session gibi temel özellikleri iyi sunan bir Python async framework’ü. Özellikle msgspec ve Controller tabanlı iç içe routing desteğini çok beğendim. Güçlü şekilde tavsiye ederim
  • Ben de yeni projede FastAPI’den Litestar’a geçtim ve hiç pişman değilim. Litestar’ın temel yapısı bile belirgin bir olgunluk ve güven veriyor
  • FastAPI’yi yıllardır kullanıyorum ama Litestar gerçekten en az bir kez denenmeyi hak ediyor gibi görünüyor
• FastAPI ile yıllardır uygulama geliştirirken benzer şikâyetler hissettim. Gerçek geliştirme pratiği ve gerçek API kalitesi ölçümünde, öğretici ve örnek odaklı FastAPI dokümantasyonunun gerçek dünyadan kopuk olduğu sık sık söyleniyor. Bu noktanın beklediğimden daha sık dile getirilmesi şaşırtıcı
  • Son dönemde Python framework dokümanlarının hepsi JavaScript kütüphaneleri gibi “öğretici + geveze blog” havasında; API ayrıntıları ve parametre açıklamaları gibi referans kısmı çok zayıf, bu da büyük hayal kırıklığı. Gerçek API referans dokümanına ihtiyaç var. Metot bazında ayrıntılı seçenekler, parametre listeleri olmalı; açıklama cümleleri yerine seçenekler düzgün biçimde belgelenmeli. Kaynak kodu eşelemeden iç rahatlatan bilgiye ulaşamamak çok can sıkıcı
• FastAPI kullanılabilir ama karmaşık uygulamalar kurarken azımsanmayacak sınırlamaları var. Framework tasarımında, Python mikroframework ekosisteminin JavaEE’nin 15 yıl önce zaten yaşadığı sorunları geç de olsa yeniden keşfetmesi bazen şaşırtıcı geliyor. Litestar oldukça iyi görünüyor. Streaming hata senaryolarının nasıl ele alındığına dair deneyimleri de merak ediyorum
• FastAPI popüler olsa da küçük projelerde tek başına starlette bile beni fazlasıyla memnun etti. Her özellik yok ama basit servisler için hiçbir eksik hissettirmiyor. Litestar ise kapsam olarak FastAPI ya da Django’ya daha yakın görünüyor
  • Son dönemde API’leri yalnızca starlette ile yapıyorum; temiz, sade ve resmî dokümantasyonu da iyi olduğu için proje boyutundan bağımsız olarak iyi ölçekleniyor
• Litestar uzun zamandır ilgimi çekiyordu ama henüz doğrudan kullanmadım. FastAPI’yi epey uzun süre kullandım ve FastAPI ile büyük bir kod tabanını yönetmenin zor olduğu yönündeki değerlendirmelerin biraz abartılı olduğunu düşünüyorum. Routing’i birkaç dosyaya bölüp import ederek büyük bir ağaç yapısı kurunca yeterince ölçeklenebilir oluyordu. Yine de büyük ölçekli yapılandırma için resmî dokümanlarda rehberlik eksikliği olduğu konusunda katılıyorum. Best practice’ler ve kişisel tercihlere göre dosyaları modüllere ayırınca yeterli ölçeklenebilirlik sağlanabiliyordu. FastAPI’de SQLAlchemy’yi doğrudan kullanmadığım için o taraftaki acıyı ne kadar hissettiğini tam paylaşamayabilirim
• Bu yazı, gerçek uygulama geliştirmede önemli noktaları çok iyi yakalamış. Litestar’ın tasarımı gerçekten etkileyici. Repository pattern hakkındaki görüşleri de merak ediyorum. Keşke ayrı bir yazıda daha detaylı anlatsa
• Yazı oldukça iyiydi. SQLAlchemy’nin kullanımı zor, durumu da karmaşık; birçok şaşırtıcı yönü var ama bazı insanların onu hiç kullanmadan nasıl geliştirme yaptığını merak ediyorum
  • Yakın zamanda kişisel bir projede peewee kullandım; çok fazla ek özelliği yok ama kendisinden bekleneni iyi yapıyor
  • Klasik SQLAlchemy ile Litestar’ın Advanced Alchemy’si arasında ciddi fark var. Eskiden pure SQL ya da SQLAlchemy kullanıyordum ama django ninja’dan Litestar’a geçerken SQLAlchemy kullanımını iyice azaltmaya başladım
  • Bu projedeki en ilginç şey, SQLAlchemy’nin eksilerini bir ölçüde telafi ediyor gibi görünmesi. Veritabanı gereken her projeye başlarken sonunda yine Django’ya dönüyorum. SQLAlchemy ve Alembic gerçekten katlanmak isteyeceğim türden acılar değil
  • SQLAlchemy kullanmanın en gerçekçi yolu bence modeller ve Alembic ile sadece şema tanımı ve migration yapmak; gerçek sorgu ve transaction yönetimini ise doğrudan SQL ile yürütmek. ORM ile sorguları yeniden kurmaya harcanan zaman fazla büyük
  • En çok asyncpg kullanıyorum