v0.1.0
Home GitHub

Architecture

This page shows how the go-web-monitor packages layer together in one diagram, then lists each layer's responsibility and the principles shared across layers.

System Overview

graph TB
    Main[cmd/tui<br/>main] -->|util.Read / util.Save| Store[(.webMonitor.json)]
    Main -->|service.New| Monitor[service.Monitor]
    Main -->|service.NewUI| UI[service.UI]
    UI -->|Ticker every minute / refresh| Monitor
    UI -->|command methods| Monitor
    Monitor -->|Check: HEAD → GET| Site[Target site]
    Monitor -->|util.CheckExpire| TLS[Target site :443]
    Monitor -->|sendEmail / TestEmail| SMTP[service.SMTP]
    SMTP --> Mail[Mail server]
    Monitor -->|Save| Store

Layers

Layer Package / File Responsibility
Entry cmd/tui/main.go Creates or reads .webMonitor.json, wires Monitor and UI, then runs
Interface internal/service/ui.go tview interface, one-minute schedule, command parsing, table and panel rendering
Monitor core internal/service/monitor.go Watch list and status table, HTTP probing, failure counting, alert triggering, SMTP config management
Mailer internal/service/smtp.go Picks plain / implicit TLS / STARTTLS by port and sends HTML email
Utilities internal/util/ JSON config file IO and SSL certificate days remaining
Data model internal/model/model.go Website, Config, MonitorData

Cross-Cutting Principles

Principle Implementation
One persistence file All state and settings live in .webMonitor.json in the current directory; no database or external service
State lives in Monitor UI holds no data and reads or writes only through Monitor getters and command methods
Shared state guarded by sync.RWMutex list, status, config, and isShow share one lock (coverage is incomplete; see Known Limitations)
Standard-library networking HTTP, TLS, and SMTP use only the standard library; the only third-party packages are tview and tcell

Further Reading

中文