почему в качестве валидации email - регулярка, когда можно использовать общепринятую функцию tls конфликт ``` sea-orm: runtime-tokio-native-tls sqlx: runtime-tokio-rustls ``` Причина долгого исполнения тестов: компиляция сервера каждый раз. ```rust Command::new("cargo") .args(["r", "--bin", "client"]) ``` 1. решение: предскомпилировать сервер, и переиспользовать. 2. Распараллелить тесты (может быть сложно) 3. **Проблема**: `DELETE FROM table;` — **медленная** операция (проверяет constraints, пишет в WAL). **TRUNCATE** — мгновенно. ```rust async fn clear_db(db: &DbConn) -> Result<(), DbErr> { db.execute_unprepared(" TRUNCATE abuse, abuse_reason, admin, \"like\", mail, refreshtoken, thread, trail, trails_visit_history, \"user\" RESTART IDENTITY CASCADE; ").await?; Ok(()) } ``` ## 1. **Токио ```toml tokio = { version = "1,<1.48", features = ["full"] } ``` --- ## 2. **SeaORM** ```toml sea-orm = { version = "=1.1.17", ... } ``` --- ## 3. **SQLx + SeaORM** **Почему это плохо**: - `sea-orm` использует `sqlx` под капотом, но с другими runtime features (`native-tls` vs `rustls`) - У вас **два пула соединений** с БД (один от SeaORM, второй от sqlx) - Миграции на SeaORM, а тесты могут использовать sqlx напрямую → **schema drift** (расхождение схемы) **Конкретный риск**: В `tests/Cargo.toml` вы подключаете оба. Если напишете тест, который использует `sqlx::query!` и `sea_orm::Entity::insert`, у вас будет **race condition** на уровне транзакций. PostgreSQL не увидит изменения из одного пула в другом до коммита, и ваши тесты будут flaky (нестабильными). **Техдолг**: Вы платите за **complexity tax** (налог на сложность) дважды: за абстракцию ORM и за прямой доступ. --- ## 4. **Storage Service: Premature abstraction, которая убьет вас** Ваша абстракция хранилища с `mirror`, `backup`, `single` стратегиями — это **over-engineering без причины**. **Почему это ошибка**: - У вас нет SLA на durability (надежность хранения) - У вас нет метрик на RTO/RPO (Recovery Time/Point Objectives) - У вас нет **idempotency** в storage operations **Конкретный баг**: В `mirror.rs` если первый write успешен, а второй — нет, у вас **silent data corruption** (тихая порча данных). У вас нет **transaction log** для отката первого write. Это **eventual consistency without reconciliation** (согласование в конечном счете без сверки). **Техдолг**: Вы построили **distributed system** там, где был достаточен `std::fs::write`. Через год, когда storage заполнится, вы не поймете, почему `mirror` стратегия оставляет мусор в старых бакетах — потому что нет garbage collection. --- ## 5. **DTO Hell: Вы создаете 3-4 структуры на каждую сущность** Посмотрите на `domain/src/client/profiles/requests.rs` и `responses.rs`. У вас: - `CreateUserRequest` - `UpdateUserRequest` - `PublicUserResponse` - `PrivateUserResponse` - `UserResponse` **Это не separation of concerns, это duplication of concerns**. Каждое изменение поля `username` — это изменение в 5 файлах и 2 миграциях. **Что вы потеряли**: **Single source of truth**. У вас нет `User` entity из домена, который бы гарантировал инварианты. Вместо этого вы полагаетесь на валидацию в каждом DTO отдельно. **Техдолг**: **Schema spread**. Когда добавите поле `last_login_at`, вы забудете обновить один из Response DTO, и клиент получит panicking deserialization. --- ## 6. **Abuse System: Security theater (имитация безопасности)** У вас есть `CreateAbuseRequest`, `abuse.rs`, `abuse_reason.rs`, но нет **rate limiting** на создание abuse-репортов. Я могу написать скрипт, который заспамит 1M репортов на один trail и **сложит вашу БД**. **Что не так**: - Нет `abuse_reports_per_user_per_hour` констрейнта - Нет `abuse_score` алгоритма (например, если 10 репортов от разных юзеров — автоматический бан) - Нет `abuse_report_fingerprint` (я могу создавать репорты с разных аккаунтов, но с одного IP) **Техдолг**: У вас есть **data model для безопасности, но нет enforcement**. Это как замок на двери без стен. --- ## 7. **Transactions: Невидимый кошмар** В `repository` трейтах у вас методы типа `create_trail`, `toggle_trail_like` — каждый **своя собственная транзакция**. **Почему это баг**: Если в use-case нужно создать trail, создать thread, поставить лайк — у вас **три отдельные транзакции**. Если последняя упадет, первые две останутся в БД. У вас **inconsistent state** без `ROLLBACK`. **Где посмотреть**: `api-core` должен принимать `&DatabaseTransaction` и выполнять все операции в ней. Сейчас у вас **autocommit hell** — каждый `repo.insert()` — это `COMMIT`. **Техдолг**: У вас нет **transactional boundaries** на уровне use-case. Это значит, ваши данные **не консистентны** в границах бизнес-операции. --- ## 8. **API Keys Middleware: Тёмная материя без тестов** В `api/src/middleware/api_key_middleware.rs` (который вы не показали, но он подключен) — вероятно, нет **integration tests**. **Что это значит**: Вы не знаете, работает ли rate limiting. Я могу brute-force API keys со скоростью 10k req/s, и ваша middleware может **не выдержать нагрузку**. **Техдолг**: У вас **нет нагрузочных тестов** на middleware. Когда ваше приложение ляжет от DDoS, вы не поймете, виноват ли `axum`, `tower`, или ваш кастомный код. --- ## 9. **Thread Model: Race condition при append** `append_trail_to_thread` — это **concurrency nightmare**. **Сценарий**: 1. User A читает thread (id=1, last_trail_id=5) 2. User B читает thread (id=1, last_trail_id=5) 3. Оба одновременно `append_trail_to_thread` с parent_id=5 4. У вас два trail'а с parent_id=5, но thread не знает, кто "победил" У вас нет **optimistic locking** (`version` поле) или `SELECT FOR UPDATE`. Это **lost update problem** на уровне приложения. **Техдолг**: У вас **нет SERIALIZABLE isolation** для критичных операций. Ваши треды могут разветвляться в невалидные структуры. --- ## 10. **Observability: Вы слепы в production** У вас есть `tracing`, но нет: - **Metrics** (`prometheus`, `metrics-rs`) - **Structured logging** (JSON logs для ELK/Loki) - **Distributed tracing** (OpenTelemetry для Jaeger/Tempo) **Что это значит**: Когда в продакшене упадет запрос, вы увидите: ``` INFO: request started INFO: request failed ``` Но не увидите: `user_id`, `trace_id`, `duration_ms`, `db_query_count`. Вы **не сможете отладить performance regression** после вашего PR. **Техдолг**: У вас **нет production-grade observability**. Это значит, вы **не сможете понять, что сломали**, когда добавите ML-фичу. --- ## 11. **Release Profile: Thin LTO — это медленный production** ```toml [profile.release] lto = "thin" ``` Для вашего уровня performance-чувствительности (RTX 3050, 24GB RAM) это **сознательный выбор скорости компиляции в ущерб runtime**. **Что это значит**: Ваш бинарник будет на 15-30% медленнее, чем мог бы быть. Для "тропиночного" приложения это не критично, но если вы планируете **batch ML inference** на GPU, вы **теряете performance** из-за неинлайненных вызовов. **Техдолг**: У вас **нет performance budget**. Вы не знаете, сколько RPS может выдержать ваш сервер, потому что не тестировали под нагрузкой с `lto = "fat"`. --- ## 12. **Migrations: Append-only log без checksums** Ваш `Migrator` — это **poor man's Flyway**. Но нет: - **Checksum** каждой миграции (если кто-то изменит старую миграцию, вы не узнаете) - **Baseline** миграции (невозможно подключиться к существующей БД) - **Repair** mode (если миграция упала на production) **Что это значит**: Если ваш DevOps-engineer случайно отредактирует `m20241005_112021_create_like.rs` на проде-сервере, `cargo run --bin migrate` **не заметит изменения** и накатит кривую схему. **Техдолг**: У вас **нет migration integrity checks**. Это значит, схема БД — **mutable history**, а не immutable log. --- ## 13. **Dependencies: 150+ crate'ов, и вы не знаете, зачем** Запустите `cargo tree | wc -l`. У вас больше 150 зависимостей для CRUD приложения. **Конкретные лишние**: - `rust-argon2` **и** `bcrypt` — два password hashing алгоритма. Выбери один. - `lazy_static` **и** `once_cell` — дублирование (once_cell в std с 1.70) - `utoipa` **и** `utoipa-swagger-ui` — генерируете OpenAPI, но нет тестов, что спецификация валидна - `opendal` — вы используете только `memory` и `fs`, но это 50+ transitive dependencies **Техдолг**: У вас **dependency bloat**. Каждый `cargo build` тянет мир, а security audit (cargo audit) будет плакать каждую неделю. --- ## 14. **Test Coverage: Hurl — это не enough** У вас 50+ hurl файлов, но **нет unit тестов** на `api-core`. Это значит, вы тестируете **только happy path** через HTTP. **Что вы не тестируете**: - **Error conditions**: Что если `TrailRepository::create` вернет `DbErr::ConnectionAcquire`? - **Edge cases**: Что если `user_id` отрицательный? (SeaORM принимает i64, но должна валидировать) - **Concurrency**: Что если 1000 потоков вызывают `toggle_trail_like` одновременно? **Техдолг**: У вас **нет property-based testing** (proptest) и **нет fuzzing** (cargo-fuzz). Вы **не нашли race conditions и integer overflow bugs**, которые 100% есть в коде. --- ## 15. **DTO Validation: Validate на уровне HTTP, а не домена** Ваша валидация в `domain` DTO — это **security theater**. Почему? ```rust #[derive(Validate)] pub struct CreateTrailRequest { #[validate(length(min = 3, max = 200))] pub title: String, } ``` Эта валидация **не вызывается автоматически**. Она вызывается в **extractor**. Если кто-то создаст `Trail` напрямую через `api-core`, минуя HTTP — валидация **пропущена**. **Правильно**: Валидация должна быть в `NewTrail` **domain entity**, и она должна быть **infallible constructor** (конструктор, который не позволит создать невалидный объект). **Техдолг**: У вас **type safety holes**. Невалидные данные могут просочиться в БД через прямой вызов api-core. --- ## Финальная правда: Это хороший прототип, но не production system Ваш проект — **MVP с правильной архитектурной формой, но без production-grade деталей**. Он выживет до первого серьезного инцидента: - **До первого DDoS** — упадет, потому что нет rate limiting - **До первого data corruption** — потеряете данные, потому что нет транзакций - **До первого security breach** — скомпрометируете API keys, потому что нет audit log - **До первого performance regression** — не поймете, что сломали, потому что нет метрик **Что делать сейчас** (порядок приоритета): 1. **Удалите `sqlx` из workspace** — используйте только SeaORM 2. **Добавьте `TransactionTrait`** во все use-кейсы в `api-core` 3. **Напишите 10 unit тестов** на `TrailService` с `MockTrailRepository` — вы поймете, где у вас **logic gaps** 4. **Запустите `cargo audit`** и пофиксите critical уязвимости (их будет 5-10) 5. **Добавьте один rate limiter** в `api_key_middleware` — поймете, насколько ваш design **fragile** Это не "у вас всё плохо". Это "у вас всё **правильно начато, но не закончено**".