ashik-z/microvest

1. Overall shape

Microvest is a server-rendered FastAPI application rather than a separate frontend/backend split. Browser requests hit FastAPI routes, which fetch data from MySQL, call market-data services, and render Jinja2 templates back to the client.

2. Request entrypoint and app wiring

backend/main.py is the application bootstrap. It likely wires the FastAPI app, mounts routers, configures templates/static assets, and connects middleware/session handling. This is the top-level composition point for the whole system.

3. Configuration and runtime boundaries

backend/config.py centralizes environment-driven settings such as MySQL connection values, the secret key, and debug mode. That keeps deployment concerns separate from business logic and makes the app portable across environments.

4. Persistence layer

backend/database.py and backend/models.py define the SQLAlchemy boundary to MySQL. The data model probably includes users, watchlist entries, portfolio holdings, and transaction records, since those are the core domain objects exposed by the README features.

5. Authentication subsystem

backend/routers/auth.py and backend/services/auth_service.py handle registration, login, and session-backed access control. The README indicates secure session cookies, itsdangerous, and bcrypt/password hashing, so auth is stateful and server-managed rather than token-only API auth.

6. Dependency injection and request context

backend/dependencies.py is the glue layer for common request-scoped concerns such as obtaining a database session and resolving the currently authenticated user. This is an important architectural boundary because it keeps routers thin and consistent.

7. Watchlist and portfolio flows

backend/routers/watchlist.py and backend/routers/portfolio.py drive the two main user workflows: tracking symbols and simulating buy/sell activity. These routes likely orchestrate both database persistence and live price lookup before rendering the corresponding page.

8. Market-data service layer

backend/services/stock_service.py is the external-data boundary. The README says it uses yfinance with 60-second caching, so this service isolates market-price retrieval from the rest of the app and reduces repeated upstream calls.

9. Dashboard aggregation

backend/routers/dashboard.py is the read-heavy summary view. It likely combines portfolio valuation, profit/loss, watchlist counts, and recent transactions into a single page, making it a presentation-level aggregation over multiple database tables and stock-service calls.

10. Inflation subsystem

backend/routers/inflation.py and backend/services/inflation_service.py are a separate analytics slice from the core trading/watchlist flows. This appears to provide macro/inflation context as an additional dashboard-style view, probably backed by an external data source distinct from the stock quotes.

11. Template layer

backend/templates/ contains page templates for login, registration, dashboard, watchlist, portfolio, and inflation, all extending base.html. This confirms the app is multi-page, server-rendered, with Tailwind/Alpine used for styling and light interactivity rather than a SPA framework.

12. Typical data flow

A request usually flows as: browser → router → dependency resolution (DB/user) → service layer → MySQL and/or external market data → template rendering → browser response. The important architectural distinction is that routers coordinate, services encapsulate business/external logic, and models/database handle persistence.

13. External dependencies that shape the design

The main external systems are MySQL for persistence and yfinance for live stock data. Their presence drives the separation between database models, cached market-data service logic, and the server-rendered pages that present the results.