sync
This commit is contained in:
parent
48f640b55d
commit
440a2fa01f
28 changed files with 1849 additions and 96 deletions
253
00-work/issues.md
Normal file
253
00-work/issues.md
Normal file
|
|
@ -0,0 +1,253 @@
|
|||
почему в качестве валидации 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**
|
||||
|
||||
Это не "у вас всё плохо". Это "у вас всё **правильно начато, но не закончено**".
|
||||
Loading…
Add table
Add a link
Reference in a new issue