Litestar đáng để thử một lần

• Litestar là một viên ngọc ít được biết đến trong số các framework web bất đồng bộ của Python
• Nhờ khả năng mở rộng nhanh và kiến trúc linh hoạt, nó có thể dễ dàng áp dụng cho nhiều loại dự án
• Cung cấp mô hình hóa dữ liệu không phụ thuộc vào các thư viện cụ thể như Pydantic
• Tích hợp SQLAlchemy rất tốt, mạnh về kết nối và quản lý cơ sở dữ liệu
• Có thể đưa vào công việc thực tế ngay nhờ các tính năng tích hợp sẵn như xác thực, caching, logging, monitoring

---

Tổng quan về Litestar

• Trong vài năm gần đây, các framework web Python async-first, dựa trên type hint ngày càng được chú ý, và Litestar là một trong số đó mà tôi đã chọn để tích lũy kinh nghiệm sử dụng
• Khi thực tế áp dụng Litestar làm framework chính trong nhiều dự án, sự tin tưởng vào lựa chọn này ngày càng tăng
• Nhiều lập trình viên web Python vẫn chưa biết đến Litestar, nên bài viết này giới thiệu các ưu điểm và điểm nổi bật chính của nó

Ví dụ và so sánh framework

• Litestar cho phép viết rất dễ dàng cả một ứng dụng web single-file cực kỳ đơn giản

  • route decorator là một hàm độc lập không gắn với đối tượng app
  • Trong ví dụ minh họa, khi truy cập /greet?name=Bob sẽ trả về “Hi, Bob!”
  • Nếu thiếu tham số bắt buộc, hệ thống tự động trả về phản hồi 400

• Khác với các microframework Python hiện có như Flask hay FastAPI, Litestar có đặc điểm kiến trúc giúp mở rộng một cách tự nhiên ở nhiều quy mô dự án

  • Cách làm của Flask hoặc FastAPI có route decorator gắn với đối tượng app nên khi tách ra nhiều file có thể phát sinh vấn đề import vòng tròn
  • Thông thường phải dùng route registry cấp dưới (Flask/Quart dùng blueprint, FastAPI dùng APIRouter, v.v.), nên hoặc làm tăng rào cản tiếp cận, hoặc buộc phải thay đổi cấu trúc
  • Nhưng với Litestar, decorator là hàm độc lập, nên việc chuyển đổi giữa app một file và cấu trúc phân tán quy mô lớn rất gọn gàng

• Nhờ kiến trúc cơ bản và cách viết tài liệu của Litestar, khái niệm router và nhóm tính năng có thể được giới thiệu ngay từ rất sớm, giúp duy trì tính nhất quán ngay cả khi xây dựng API phức tạp

  • Tính composability là thế mạnh, như dependency injection, phân quyền, chia sẻ config theo route
  • Có thể đăng ký cùng một route nhiều lần để áp dụng xác thực hoặc dependency khác nhau theo từng môi trường

Mô hình hóa không phụ thuộc vào Pydantic

• FastAPI và một số framework khác phụ thuộc dữ liệu rất mạnh vào Pydantic

  • Pydantic mạnh về kiểm tra và serialize dữ liệu dựa trên kiểu, nhưng khó tích hợp trực tiếp với ORM (SQLAlchemy)
  • Trong thực tế, thường phải viết riêng model SQLAlchemy và model Pydantic, khá phiền phức

• Litestar hỗ trợ tổng quát nhiều kiểu khác nhau ngoài Pydantic như dataclasses, msgspec, attrs, SQLAlchemy model

  • Có serialization plugin protocol nên khả năng mở rộng cao
  • Tích hợp chức năng tự động trích xuất DTO (data transfer object), nên chỉ cần thay đổi lớp dữ liệu gốc là DTO tự phản ánh theo
  • Cũng có thể khai báo đơn giản việc loại trừ một phần field, bao gồm field, ánh xạ tên, DTO cho partial update, v.v.
  • Nhờ vậy có thể tránh việc khai báo lặp field của model và các lỗi thường gặp trong quá trình đồng bộ thủ công

Tích hợp với SQLAlchemy và giới thiệu Advanced Alchemy

• SQLAlchemy ORM gần như là chuẩn thực tế cho kết nối DB trong Python

  • Litestar có mức tích hợp rất tốt với SQLAlchemy, như tự động serialize schema, tự động hóa DTO, plugin quản lý session, plugin tổng hợp, v.v.

• Thư viện Advanced Alchemy (do đội ngũ Litestar duy trì) mở rộng thêm năng lực của SQLAlchemy

  • Cung cấp nhiều tính năng cải thiện chất lượng như PK lớn không phụ thuộc database, timestamp tự động, khóa UUID, kiểu JSON, tích hợp migration Alembic, Seed/Export, v.v.
  • Một tính năng đáng chú ý là hỗ trợ trừu tượng hóa repository và service layer, tự động cung cấp nhiều chức năng lưu trữ như CRUD và pagination
  • Khác với Django, ở các framework có hướng dẫn cấu trúc không mạnh, đây là cách tổ chức đáng khuyến nghị để đưa repository/service layer vào

Các đặc điểm khác và tính năng hỗ trợ tích hợp sẵn

• Litestar cũng cung cấp sẵn trong framework các thành phần như hệ thống xác thực (guard function, middleware), caching (stores), logging, phản hồi lỗi chuẩn hóa, metric dựa trên Prometheus/OpenTelemetry, hỗ trợ htmx
• Khác với các microframework khác, khi triển khai một số tính năng sẽ không cần đi tìm thêm thư viện bên ngoài hoặc tự viết glue code tùy biến
• Vẫn giữ được sự gọn nhẹ của một "microframework", nhưng khi cần mở rộng hoặc thêm tính năng thì có thể dùng ngay theo nhu cầu
• Đây không hẳn là bản thay thế cho Django/Flask, mà là một khái niệm mang các điểm mạnh của framework ở ngôn ngữ khác như Java Spring Boot (cấu trúc ban đầu + tính tiện dụng, v.v.) vào Python theo cách Pythonic
• Nhìn chung, đây là một lựa chọn có năng suất cao và lợi thế cấu trúc cho phát triển web Python trong thực tế

Kết luận

• Litestar đang nổi lên như một framework mà lập trình viên web Python nên cân nhắc ít nhất một lần, nhờ tính bất đồng bộ, nền tảng kiểu dữ liệu, khả năng mở rộng linh hoạt, mô hình dữ liệu không bị bó chặt, ORM xuất sắc và nhiều tính năng tích hợp sẵn
• Kết quả từ việc dùng lặp lại trong các dự án thực tế cho thấy nó có năng suất và khả năng bảo trì cao ngay cả trong nhiều môi trường dự án khác nhau như startup
• Hy vọng các lập trình viên sẽ đưa Litestar vào danh sách lựa chọn cho dự án web Python tiếp theo

[minhoryang]

Vấn đề “import vòng lặp” của Python chẳng phải đã có hướng giải quyết khá rõ ràng rồi sao? Để xem đó là một vấn đề nghiêm trọng thì tôi thấy vẫn hơi gượng ép.

[GN⁺]

Ý kiến Hacker News

• Trong 1 năm qua tôi đã phát triển một dự án backend quy mô lớn bằng FastAPI. Ban đầu tôi bắt đầu theo đúng phong cách của tutorial chính thức, nhưng tôi thấy khó chịu với template chính thức của FastAPI vốn dồn toàn bộ CRUD vào một file, cũng như cách quản lý dependency của nó. Khi dùng SQLModel thì lại gặp nhiều giới hạn như không hỗ trợ mô hình đa hình, và dù cộng đồng có gửi PR cải thiện thì cũng không được review suốt nhiều tháng, khiến tôi nghi ngờ liệu nó có thực sự được bảo trì hay không. Tài liệu cũng thiếu các tham chiếu đủ dùng trong thực tế nên cuối cùng tôi phải lục cả source code. Làm CRUD nhanh thì ổn, nhưng để xây dựng hệ thống phức tạp thì nó giống như phải chồng thêm một framework lên trên framework khác, nên tôi không định khuyến nghị nó. Từ ngày mai tôi sẽ lên kế hoạch migrate sang Litestar
  • Nếu muốn tìm hiểu các ví dụ ứng dụng lớn thực tế với FastAPI, có lẽ sẽ hữu ích khi tham khảo mã server của repo polarsource/polar. Ở đó tập hợp khá tốt các ví dụ scale-out thực tế như xác thực, kiểm thử, v.v., nên tôi định học bằng cách bám theo cách triển khai trong repo này
  • Tôi đang bắt đầu tìm hiểu thiết kế ứng dụng thiên về API, và từ bài này tôi đã học được nhiều điểm về kiến trúc và công cụ mà trước đây chưa nghĩ tới. Tôi cũng định thử dùng Litestar. Cảm ơn vì những ý kiến và bài viết hữu ích
  • Tôi không đồng ý rằng SQLModel bị nhấn mạnh quá mức trong tutorial chính thức của FastAPI. Ở trang đầu còn không nhắc tới SQLModel, và chỉ nói đến nó trong trang giải thích cách kết nối cơ sở dữ liệu quan hệ. Việc tutorial dùng một ORM cụ thể là lựa chọn tự nhiên, và nếu SQLModel không phù hợp thì tôi nghĩ người dùng nên chọn phương án khác. Bản thân tôi cũng đã xem tutorial rồi quyết định dùng plain SQLAlchemy
  • Tôi đọc tài liệu Litestar thì thấy nó còn có sẵn hệ thống event. Đây là tính năng mà tôi đã phải mất vài tuần tự xây trong FastAPI, còn Litestar thì có sẵn ngay từ đầu
  • Tôi cũng tự hỏi liệu Litestar có những giới hạn riêng hay không. Dù cộng đồng, tài liệu và thảo luận của nó ít hơn FastAPI, bạn vẫn nghĩ nó phù hợp hơn cho các ứng dụng phức tạp chứ? Tôi muốn nghe thêm ý kiến về điểm này
• Litestar rất xuất sắc để xây dựng backend API. Tôi đang dùng trực tiếp và đủ thích để khuyến nghị mạnh. Advanced Alchemy cũng ngày càng tốt hơn. Ngay cả các website kiểu render template phía server theo lối cũ cũng hoàn toàn có thể làm bằng Litestar, và nó còn tích hợp sẵn plugin cho HTMX. Tuy vậy, các pattern để thiết kế endpoint API lại hơi gượng gạo khi áp dụng cho các endpoint render phía server truyền thống như kiểm tra form hay redirect. Bản thân Litestar cũng chưa có tính năng xử lý form đúng nghĩa, nên khá khó để xử lý chuẩn lỗi theo từng field của form. Pattern dùng @post("/route", exception_handlers={...}) tạo cảm giác hơi gượng. Tôi hy vọng sau này sẽ có công cụ tích hợp tốt hơn và trải nghiệm phát triển được cải thiện thêm
  • Tôi chưa từng dùng Litestar trực tiếp, nhưng có lẽ chỉ cần tự tạo một decorator như @postform để xử lý toàn bộ phần liên quan đến form là được chăng
• Litestar là một web framework cho Python. Chia sẻ trước thông tin này cho ai đang tò mò
  • Cũng có người nói nhờ vậy mà họ tiết kiệm được thời gian
• Tôi đã phục vụ đồng thời JSON và HTML dựa trên template bằng Litestar hơn 1 năm nay. Nó nhanh hơn FastAPI, là một framework Python async gọn nhẹ nhưng vẫn có đủ các tính năng thiết yếu như xác thực và session. Tôi đặc biệt thích việc nó hỗ trợ msgspec và nested routing dựa trên Controller. Rất đáng khuyến nghị
  • Tôi cũng đã chuyển dự án mới từ FastAPI sang Litestar, và dùng rất ổn, không hề hối tiếc. Chỉ riêng phần nền tảng mặc định của Litestar thôi cũng đã cho cảm giác hoàn thiện và đáng tin cậy rõ rệt
  • Tôi đã dùng FastAPI nhiều năm, nhưng Litestar cũng có vẻ rất đáng để thử ít nhất một lần
• Tôi đã phát triển ứng dụng bằng FastAPI trong nhiều năm và cũng có những bất mãn tương tự. Trong phát triển thực chiến và khi đánh giá chất lượng API thật sự, tài liệu FastAPI vốn thiên về tutorial và ví dụ thường bị cho là xa rời thực tế. Tôi khá ngạc nhiên vì điểm này bị nhắc đến thường xuyên hơn tôi tưởng
  • Gần đây tài liệu của các framework Python đều cho cảm giác giống thư viện JavaScript kiểu 'tutorial + blog lắm lời', thiếu hẳn phần tham chiếu về API chi tiết và giải thích tham số, điều này thực sự gây thất vọng. Cần có tài liệu tham chiếu API đúng nghĩa. Tôi muốn có mô tả chi tiết các tùy chọn theo từng method, bảng tổng hợp tham số, và cách ghi rõ option thay vì chỉ có vài câu chú thích. Cách làm hiện tại, nơi phải lục cả source code mới tìm được thông tin thỏa đáng, thật sự rất bất tiện
• FastAPI vẫn dùng được, nhưng để xây dựng ứng dụng phức tạp thì nó có không ít giới hạn. Đôi lúc tôi ngạc nhiên khi thấy hệ sinh thái microframework Python đang tái khám phá muộn màng những vấn đề mà JavaEE đã trải qua từ 15 năm trước. Litestar trông khá ổn. Tôi cũng tò mò về kinh nghiệm xử lý các trường hợp lỗi khi streaming
• Dù FastAPI nổi tiếng, với các dự án nhỏ thì chỉ riêng starlette thôi tôi đã thấy rất hài lòng. Nó không có đủ mọi tính năng, nhưng với dịch vụ đơn giản thì hoàn toàn không thiếu. Litestar có vẻ ở phạm vi gần với FastAPI hoặc Django hơn
  • Gần đây tôi xây API chỉ với starlette, vì nó sạch sẽ, ngắn gọn, tài liệu chính thức cũng tốt nên khả năng mở rộng ổn bất kể quy mô dự án
• Tôi luôn quan tâm đến Litestar nhưng vẫn chưa trực tiếp dùng thử. Tôi đã dùng FastAPI khá lâu, và cảm giác rằng FastAPI khó quản lý codebase lớn có phần hơi cường điệu. Chỉ cần chia routing ra nhiều file rồi import để tạo cấu trúc cây lớn là vẫn mở rộng tốt. Tuy vậy, tôi đồng ý là hướng dẫn chính thức về cách tổ chức quy mô lớn còn thiếu. Nếu chia file theo best practice và sở thích cá nhân, tách module hợp lý thì vẫn đảm bảo được khả năng mở rộng. Tôi không trực tiếp dùng SQLAlchemy trong FastAPI nên có lẽ không thật sự đồng cảm với nỗi khổ ở phần đó
• Đây là bài viết chỉ ra rất đúng những điểm quan trọng trong phát triển ứng dụng thực tế. Thiết kế của Litestar thực sự hấp dẫn. Tôi cũng đang chờ nghe thêm quan điểm về repository pattern. Sẽ rất hay nếu có một bài riêng nói sâu về nó
• Bài viết khá hay. SQLAlchemy khó dùng và trạng thái của nó phức tạp đến mức có nhiều điều gây bất ngờ, nên tôi tò mò không biết có ai phát triển mà hoàn toàn không dùng nó không
  • Gần đây tôi thử làm một dự án cá nhân bằng peewee, không có nhiều tính năng phụ trợ nhưng làm tốt đúng phần việc của nó
  • SQLAlchemy truyền thống và Advanced Alchemy của Litestar (dù cũng dựa trên SQLAlchemy) khác nhau khá nhiều. Trước đây tôi dùng pure SQL hoặc SQLAlchemy, nhưng từ khi chuyển từ django ninja sang Litestar thì đang dần giảm hẳn mức độ dùng SQLAlchemy
  • Điểm thú vị nhất của dự án này là nó có vẻ bù đắp được phần nào những nhược điểm của SqlAlchemy. Mỗi lần bắt đầu một dự án cần database là tôi lại quay về với Django. SqlAlchemy và Alembic là nỗi đau mà tôi không thật sự muốn tiếp tục chịu đựng
  • Tôi nghĩ cách thực tế nhất để dùng SQLAlchemy là chỉ dùng model và Alembic để định nghĩa schema, migration, còn truy vấn thật hay quản lý transaction thì viết SQL trực tiếp. Thời gian tiêu tốn để tái cấu trúc truy vấn bằng ORM là quá lớn
  • Tôi chủ yếu dùng asyncpg