Минусы Litestar
Внезапно вспомнил, что я меинтейнер фреймворка Litestar.
Для тех, кто пропустил:
> Litestar не является микро-фреймворком. В отличие от таких фреймворков, как FastAPI, Starlette или Flask,
> Litestar изначально включает множество функций, необходимых для типичного современного веб-приложения,
> таких как интеграция с ORM, клиентские и серверные сессии, кэширование, поддержка OpenTelemetry и многое другое.
from dataclasses import dataclass
from litestar import Litestar, post
@dataclass
class User:
name: str
@post(path="/")
async def index(data: User) -> User:
return data
app = Litestar(route_handlers=[index])
И он классный:
- Быстрый
- Работает с Pydantic, msgspec и даже базовые dataclasses в качестве моделей
- Предоставляет базовые примитивы для работы с логикой: DTOs, Repository, Service (часть из них в advanced_sqlalchemy, очень удобно для крудов)
- Умеет из коробки в аутентификацию, метрики, DI, CORS, CSRF, кеширование, логирование, мониторинг, вебсокеты, htmx, сессии, загрузку файлов, разные ORMки и много всего еще
- Можно делать не только API, но и нормальные шаблончики
- Он с нами уже несколько лет, он работает
- А еще его делает большая команда, а не один человек
Кароче, просто лучший фреймворк (кроме Django, конечно).
Но! Сегодня речь пройдет про минусы. Которые скоро пофиксят в v3 (или которые все еще будут с нами)
Минусы
1. Самое главное: DI на именах. Да. Вот так:
class UserController(Controller):
path = "/user"
dependencies = {"user": Provide(retrieve_db_user)}
@patch(path="/{user_id:uuid}") #
async def get_user(self, user: User) -> User: ...
Что очень плохо. Тип user, который мы указываем в dependencies и в параметрах может не совпасть. Есть некоторая валидация для такого в рантайме, но все равно очень рисково.
Планы? Я предложил использовать dishka в качестве дефолтного DI, а старый задеприкейтить.
Высказать свое обоснованное мнение можно тут (или просто лайкнуть пост): https://github.com/orgs/litestar-org/discussions/4377
Хочу верить, что мы сможем поправить данную проблему в v3, ваши голоса – могут помочь :)
2. DI в middleware. А точнее отсутствие DI в middleware. Пока что приходится прокидывать зависимости через app.state, что очень криво. Данная проблема признана ошибкой дизайна и будет исправлено в v3, ура!
3. Своя схема для OpenAPI. Litestar переписал дефолтную схему pydantic, что позволило использовать более строгую схему, но переодически новые типы отваливаются. Например, pydantic.Json не обработан, имеет кривую схему. Сейчас мы обсуждаем стоит ли откатиться до дефолтной схемы. Стоит ли?
4. PydanticPlugin игнорирует ConfigDict, который объявлен в самой моделе, в v3 будет пофикшено. Сейчас параметры вроде by_alias и round_trip надо передавать в плагин. Что свело меня с ума, искал ошибку несколько часов
5. CLI местами разваливается, очень много багов и плохая читаемость
6. Очень сырая документация. Очень плохая навигация и структура, очень мало примеров, мало людей ее читало, мало людей находило проблемы, мало людей присылало PRы. Тут нужна ваша помощь очень сильно!
Итог
Отличный фреймворк, у которого есть некоторое количество детских проблем и ошибок проектирования. Но что отличает? Про них говорят, их исправляют.
Полный роадмап для версии v3: https://github.com/litestar-org/litestar/issues/4009
Обсуждение: Как вам Litestar? Какие минусы я забыл? Каких фичей не хватает? Что показалось сложным? Буду рад обратной связи :)
0
Показать ещё
