Litestar layak dilirik

• Litestar adalah permata tersembunyi di antara framework web async Python
• Berkat skalabilitas yang cepat dan arsitektur yang fleksibel, framework ini mudah diterapkan ke berbagai proyek
• Menyediakan pemodelan data yang tidak bergantung pada library tertentu seperti Pydantic
• Integrasi SQLAlchemy sangat baik, sehingga unggul dalam koneksi dan pengelolaan basis data
• Fitur bawaan yang praktis seperti autentikasi, caching, logging, dan monitoring membuatnya bisa langsung dipakai di lingkungan kerja

---

Gambaran umum Litestar

• Dalam beberapa tahun terakhir, framework web Python async-first berbasis type hint semakin mendapat perhatian, dan Litestar dipilih sebagai salah satunya untuk memperdalam pengalaman penggunaan
• Setelah mengadopsi Litestar sebagai framework utama di beberapa proyek nyata, keyakinan terhadap pilihan tersebut terus meningkat
• Karena banyak developer web Python yang masih belum mengenal Litestar, tulisan ini memperkenalkan kelebihan utama dan ciri khasnya

Contoh dan perbandingan framework

• Litestar memudahkan pembuatan aplikasi web satu file yang sangat sederhana

  • Route decorator adalah fungsi independen yang tidak terikat pada objek aplikasi
  • Pada kode contoh, mengakses /greet?name=Bob akan mengembalikan “Hi, Bob!”
  • Jika parameter wajib tidak ada, respons 400 akan diberikan secara otomatis

• Berbeda dari microframework Python yang sudah ada seperti Flask dan FastAPI, Litestar memiliki karakteristik struktural yang membuatnya meluas secara alami pada proyek dengan berbagai skala

  • Pada pendekatan Flask atau FastAPI, routing decorator terikat pada objek aplikasi sehingga saat dipisah ke banyak file ada potensi muncul masalah circular import
  • Biasanya perlu memanfaatkan route registry turunan (Flask/Quart memakai blueprint, FastAPI memakai APIRouter, dan sebagainya), sehingga hambatan awal lebih tinggi atau perubahan struktur menjadi perlu
  • Namun di Litestar, decorator adalah fungsi independen, sehingga perpindahan antara aplikasi satu file dan struktur terdistribusi skala besar menjadi sangat ringkas

• Berkat arsitektur dasar dan cara penulisan dokumentasi di Litestar, konsep router dan pengelompokan fitur bisa diperkenalkan sejak sangat awal, sehingga lebih mudah menjaga konsistensi saat menyusun API yang kompleks

  • Kekuatan utamanya ada pada composability seperti dependency injection, otorisasi, dan berbagi config per rute
  • Rute yang sama bisa didaftarkan beberapa kali sehingga autentikasi atau dependensi yang berbeda dapat diterapkan sesuai lingkungan

Pemodelan yang lepas dari ketergantungan pada Pydantic

• FastAPI dan sejenisnya sangat bergantung pada data berbasis Pydantic

  • Pydantic unggul untuk validasi dan serialisasi data berbasis tipe, tetapi sulit diintegrasikan langsung dengan ORM (SQLAlchemy)
  • Dalam praktik kerja, ini merepotkan karena model SQLAlchemy dan model Pydantic harus ditulis terpisah

• Litestar mendukung berbagai tipe secara umum, bukan hanya Pydantic tetapi juga dataclasses, msgspec, attrs, dan model SQLAlchemy

  • Memiliki serialization plugin protocol untuk meningkatkan ekstensibilitas
  • Dilengkapi fitur ekstraksi otomatis data transfer object (DTO), sehingga jika kelas data sumber diubah maka DTO ikut diperbarui otomatis
  • Pengecualian sebagian field, penyertaan, pemetaan nama, dan DTO untuk partial update juga bisa dideklarasikan dengan sederhana
  • Dengan demikian, duplikasi deklarasi field model serta kesalahan yang sering terjadi saat sinkronisasi manual dapat dihindari

Integrasi dengan SQLAlchemy dan pengenalan Advanced Alchemy

• SQLAlchemy ORM adalah standar de facto untuk koneksi basis data di Python

  • Litestar sangat unggul dalam integrasi seperti serialisasi skema otomatis SQLAlchemy, otomatisasi DTO, plugin manajemen sesi, dan plugin gabungan

• Melalui library Advanced Alchemy (dipelihara oleh tim Litestar), kemampuan SQLAlchemy diperluas

  • Menyediakan berbagai fitur peningkatan kualitas seperti PK besar yang database-agnostic, timestamp otomatis, kunci UUID, tipe JSON, integrasi migrasi Alembic, serta Seed/Export
  • Fitur yang paling menonjol adalah dukungan abstraksi repository dan service layer, yang secara otomatis menyediakan berbagai fungsi penyimpanan seperti CRUD dan pagination
  • Tidak seperti Django, pada framework yang panduan strukturnya lebih longgar, ini menghadirkan pola organisasi yang layak direkomendasikan untuk mengadopsi repository/service layer

Fitur lain dan dukungan bawaan

• Litestar juga menyediakan secara internal sistem autentikasi (fungsi guard, middleware), caching (stores), logging, respons masalah yang terstandar, metrik berbasis Prometheus/OpenTelemetry, serta dukungan htmx
• Berbeda dari microframework lain, untuk menerapkan sebagian fitur tersebut tidak perlu mencari library eksternal terpisah atau menulis glue code kustom
• Ia tetap mempertahankan kesederhanaan sebuah "microframework", tetapi saat perlu diperluas atau memakai fitur tambahan, semuanya bisa langsung dimanfaatkan sesuai kebutuhan
• Konsepnya bukan sekadar pengganti Django/Flask, melainkan menggabungkan kekuatan framework bahasa lain seperti Java Spring Boot (struktur awal + kemudahan) ke dalam pendekatan yang Pythonic
• Secara keseluruhan, ini adalah opsi dengan produktivitas tinggi dan keunggulan struktural untuk pengembangan web Python di dunia kerja

Kesimpulan

• Berkat async, berbasis tipe, fleksibel untuk diperluas, pemodelan data yang tidak terlalu ketat, serta ORM dan fitur bawaan yang sangat baik, Litestar muncul sebagai framework yang wajib setidaknya sekali dipertimbangkan oleh developer web Python
• Dari hasil penggunaan berulang di proyek nyata, terbukti memiliki produktivitas dan kemudahan pemeliharaan yang tinggi, termasuk di lingkungan startup dan berbagai jenis proyek
• Diharapkan para developer memasukkan Litestar sebagai salah satu opsi saat merencanakan proyek web Python berikutnya

[minhoryang]

Bukankah untuk "masalah circular import" di Python sudah ada solusi yang cukup jelas? Jadi rasanya agak kurang tepat kalau dianggap sebagai masalah besar.

[GN⁺]

Opini Hacker News

• Selama setahun terakhir saya mengembangkan proyek backend skala besar dengan FastAPI. Saya memulainya mengikuti gaya tutorial resmi, tetapi merasa tidak nyaman dengan template resmi FastAPI yang seolah menyuruh menaruh semua CRUD dalam satu file serta cara pengelolaan dependensinya. Saat memakai SQLModel, ada berbagai keterbatasan seperti tidak mendukung model polimorfik, dan bahkan ketika ada PR perbaikan dari komunitas, berbulan-bulan lamanya tidak juga direview, sehingga saya meragukan apakah benar-benar dirawat dengan baik. Dokumentasinya juga kurang memiliki referensi yang benar-benar praktis, jadi pada akhirnya saya harus membongkar source code. Untuk membuat CRUD dengan cepat memang lumayan, tetapi untuk membangun sistem kompleks rasanya seperti menumpuk satu framework lagi di atas framework yang sudah ada, jadi saya tidak berniat merekomendasikannya. Mulai besok saya berencana migrasi ke Litestar
  • Jika ingin mempelajari contoh aplikasi besar FastAPI yang benar-benar praktis, sepertinya akan membantu melihat kode server repo polarsource/polar. Contoh autentikasi, testing, dan kasus scale-out nyata terkumpul dengan baik di sana, jadi saya ingin belajar dengan mengikuti cara implementasi repo ini
  • Saya sedang mulai mempelajari desain aplikasi yang berpusat pada API, dan dari tulisan ini saya belajar banyak poin arsitektur dan tool yang sebelumnya tidak terpikirkan. Saya juga jadi ingin mencoba Litestar. Terima kasih atas opini dan tulisannya yang berguna
  • Saya tidak setuju bahwa SQLModel terlalu ditekankan dalam tutorial resmi FastAPI. Di halaman awal bahkan tidak ada penyebutan SQLModel, dan itu hanya dibahas di halaman penjelasan koneksi database relasional. Memakai ORM tertentu dalam tutorial adalah pilihan yang wajar, dan kalau SQLModel tidak cocok, menurut saya pengguna tinggal memilih opsi lain. Saya sendiri setelah melihat tutorial justru memutuskan memakai plain SQLAlchemy
  • Setelah membaca dokumentasi Litestar, ternyata sistem event juga sudah built-in. Di FastAPI saya sampai menghabiskan beberapa minggu untuk membuat fitur itu sendiri, sementara di Litestar sudah tersedia sejak awal
  • Saya juga merasa Litestar mungkin punya keterbatasan tertentu. Walaupun komunitas, dokumentasi, dan diskusinya lebih sedikit daripada FastAPI, apakah menurut Anda tetap lebih cocok untuk aplikasi kompleks? Saya penasaran dengan pendapat soal itu
• Litestar sangat bagus untuk membangun backend API. Saya memakainya langsung dan cukup yakin untuk sangat merekomendasikannya. Advanced Alchemy juga makin lama makin bagus. Situs kuno yang memakai server-side template rendering pun masih sangat bisa dibuat dengan Litestar, dan plugin untuk HTMX juga sudah built-in. Namun, pola-pola yang dirancang untuk endpoint API terasa agak canggung saat dipakai pada endpoint server render tradisional seperti validasi form dan redirect. Litestar sendiri belum punya fitur pemrosesan form dalam arti yang sesungguhnya, jadi agak sulit menangani error per field form dengan baik. Pola yang memanfaatkan @post("/route", exception_handlers={...}) terasa canggung. Saya berharap ke depan ada tool bawaan yang lebih baik dan peningkatan developer experience
  • Saya belum pernah memakai Litestar langsung, tetapi bukankah bisa saja membuat decorator sendiri seperti @postform yang menangani semua proses terkait form?
• Litestar adalah framework web Python. Saya membagikan info ini lebih dulu untuk yang penasaran
  • Ada juga yang bilang jadi hemat waktu berkat info itu
• Sudah lebih dari setahun saya menjalankan layanan JSON dan HTML berbasis template sekaligus dengan Litestar. Performanya lebih cepat daripada FastAPI, dan ini adalah framework Python async yang ringan tetapi tetap lengkap dengan fitur penting seperti autentikasi dan session. Saya sangat suka dukungan msgspec dan nested routing berbasis Controller. Sangat direkomendasikan
  • Saya juga beralih dari FastAPI ke Litestar untuk proyek baru, dan sejauh ini memakainya tanpa penyesalan. Bahkan hanya dari basis default Litestar saja sudah terasa matang dan meyakinkan
  • Saya sudah memakai FastAPI selama beberapa tahun, tetapi Litestar tampaknya tetap sangat layak untuk dicoba setidaknya sekali
• Selama beberapa tahun membangun aplikasi dengan FastAPI, saya merasakan keluhan yang mirip. Dalam pengembangan nyata dan pengukuran kualitas API yang sesungguhnya, dokumentasi FastAPI yang berfokus pada tutorial dan sampel sering dinilai jauh dari kebutuhan dunia nyata. Agak mengejutkan bahwa poin ini ternyata cukup sering dikritik
  • Belakangan ini saya sangat kecewa karena dokumentasi framework Python semuanya terasa seperti library JavaScript: semacam 'tutorial + blog cerewet', dan kekurangan referensi seperti detail API serta penjelasan parameter. Yang dibutuhkan adalah dokumentasi referensi API yang sesungguhnya. Harusnya ada penjelasan detail opsi per method, ringkasan parameter, dan opsi yang ditandai dengan benar alih-alih hanya kalimat komentar. Sangat tidak nyaman bahwa saat ini untuk menemukan informasi yang benar-benar jelas kita tetap harus mengorek source code
• FastAPI tetap cukup berguna, tetapi untuk membuat aplikasi kompleks ada cukup banyak batasannya. Kadang mengejutkan melihat ekosistem microframework Python seperti terlambat menemukan kembali isu-isu yang sudah dialami JavaEE 15 tahun lalu. Litestar tampak cukup bagus. Saya juga penasaran dengan praktik terbaik dalam menangani kasus error pada streaming
• FastAPI memang populer, tetapi untuk proyek kecil saya sangat puas hanya dengan starlette. Memang tidak punya semua fitur, tetapi untuk layanan sederhana sudah lebih dari cukup. Litestar tampaknya berada di cakupan yang lebih dekat ke FastAPI atau Django
  • Belakangan ini saya membuat API hanya dengan starlette, dan menurut saya ini bersih, ringkas, dokumentasi resminya juga bagus, serta skalabel tanpa terlalu bergantung pada ukuran proyek
• Saya selalu tertarik pada Litestar, tetapi belum pernah mencobanya langsung. Saya sudah cukup lama memakai FastAPI, dan menurut saya anggapan bahwa FastAPI sulit mengelola codebase besar agak dibesar-besarkan. Dengan memisahkan routing ke beberapa file, meng-import-nya, lalu membentuk struktur pohon besar, skalanya tetap bisa diperluas dengan baik. Namun saya setuju bahwa panduan resmi soal struktur skala besar masih kurang. Dengan best practice dan pembagian file per modul sesuai preferensi masing-masing, skalabilitas sebenarnya masih bisa dijaga dengan baik. Saya sendiri tidak memakai SQLAlchemy secara langsung di FastAPI, jadi mungkin saya tidak terlalu bisa berempati dengan rasa sakit di bagian itu
• Ini tulisan yang sangat tepat menangkap poin-poin penting dalam pengembangan aplikasi nyata. Desain Litestar benar-benar menarik. Saya juga menantikan pandangan soal repository pattern. Akan bagus kalau dibahas dalam posting terpisah
• Tulisannya cukup keren. SQLAlchemy sulit ditangani dan statusnya kompleks dengan banyak hal yang mengejutkan, jadi saya penasaran apakah ada orang yang benar-benar membangun tanpa memakainya sama sekali
  • Baru-baru ini saya mencoba membangun proyek pribadi dengan peewee; memang tidak punya banyak fitur tambahan, tetapi tugas utamanya dikerjakan dengan baik
  • SQLAlchemy tradisional dan Advanced Alchemy milik Litestar cukup berbeda. Sebelumnya saya memakai pure SQL atau SQLAlchemy, tetapi setelah pindah dari django ninja ke Litestar, saya justru mulai mengurangi pemakaian SQLAlchemy secara keseluruhan
  • Hal yang paling menarik dari proyek ini adalah tampaknya ia bisa menutupi beberapa kekurangan SqlAlchemy. Setiap kali mulai proyek yang butuh DB, pada akhirnya saya selalu kembali ke Django. SqlAlchemy dan Alembic adalah jenis penderitaan yang tidak ingin saya tanggung kalau tidak perlu
  • Menurut saya cara paling realistis memakai SQLAlchemy adalah memakai model dan Alembic hanya untuk definisi skema dan migrasi, sementara query dan manajemen transaksi yang sebenarnya ditulis langsung dengan SQL. Waktu yang habis untuk menyusun ulang query lewat ORM terlalu besar
  • Saya paling sering memakai asyncpg