entities
13
Back to Projects
Project Detail
GEBEYA Multi Vender API
A single-repository backend API (NestJS) implementing a multi-vendor e-commerce platform. Provides user authentication, store and product management, cart and order lifecycle, payment integration (Chapa + placeholders for Stripe/Flutterwav...
Backend EngineerDuration: Duration unspecifiedType: platform
Key Achievement Metrics
swagger_path
/api-docs
Architecture View
Processing state: architecture signal graph is initializing...
Decision Log
Use a single NestJS monolith with CQRS
Simpler deployment and development iteration while obtaining separation of concerns for commands vs queries.
Trade-off: Monolith simplifies cross-module transactions but centralizes failure blast radius; moving to microservices later requires extracting handlers and event contracts.
Cookie-based JWT for session state (access + refresh tokens)
Reduce XSS risk compared to localStorage; cookies allow automatic sending by browsers for session endpoints.
Trade-off: Requires CSRF mitigation for state-changing endpoints; cookies complicate native mobile clients (requires explicit cookie handling).
TypeORM synchronize: true in TypeOrmModule
Rapid schema iteration during development and prototyping.
Trade-off: Not safe for production migrations (risk of data loss / drift) — should be replaced by explicit migrations for production.
Architecture Narrative
Challenge
Provide a centralized HTTP API for merchants and customers to list products, manage stores and carts, place and pay for orders, and handle webhooks and notifications in a transactional manner.
Solution
Monolithic NestJS application structured as layered controllers -> CQRS (CommandBus/QueryBus) handlers -> TypeORM repositories -> PostgreSQL, with domain events via EventEmitter2 for asynchronous notifications.
Result
Key measurable signals: entities (13), swagger_path (/api-docs).
Trade-off Matrix
| Dimension | Selected Option | Impact | Compromise |
|---|---|---|---|
| Monolith with in-process events | Monolithic NestJS + EventEmitter2 | Faster development, simpler debugging and local testing | Harder to guarantee event delivery across instances; not ready for large distributed scale |
| Cookie-based tokens vs Authorization header | httpOnly cookies (access + refresh) | Lower XSS exposure and seamless browser session behavior | Requires CSRF protection; harder for native/mobile clients |
What I'd Do Differently
+
Replace schema sync with explicit migrations: set synchronize: false, add TypeORM migrations and a CI step validating migrations to prevent production drift.
+
Add distributed observability: integrate OpenTelemetry/Prometheus + structured logging (stdout JSON) and error tracing to make production incidents diagnosable without DB-only logs.