Enable prettier prose wrapping for markdown
Add proseWrap: "always" to .prettierrc so markdown prose is hard-wrapped at 80 columns.
This commit is contained in:
parent
818accc454
commit
cb8d47d7aa
@ -1,3 +1,4 @@
|
||||
{
|
||||
"tabWidth": 4
|
||||
"tabWidth": 4,
|
||||
"proseWrap": "always"
|
||||
}
|
||||
|
||||
65
README.md
65
README.md
@ -1,4 +1,7 @@
|
||||
NetWatch is an MIT-licensed JavaScript single-page application by [@sneak](https://sneak.berlin) that provides real-time network latency monitoring to common internet hosts, displayed with color-coded figures and sparkline graphs, served from a static bucket or Docker container.
|
||||
NetWatch is an MIT-licensed JavaScript single-page application by
|
||||
[@sneak](https://sneak.berlin) that provides real-time network latency
|
||||
monitoring to common internet hosts, displayed with color-coded figures and
|
||||
sparkline graphs, served from a static bucket or Docker container.
|
||||
|
||||
## Getting Started
|
||||
|
||||
@ -22,27 +25,42 @@ docker run -p 8080:8080 netwatch
|
||||
|
||||
## Rationale
|
||||
|
||||
When debugging network issues, it's useful to have a persistent at-a-glance view of latency and reachability to multiple well-known internet endpoints. NetWatch provides this as a zero-dependency SPA that can be deployed anywhere static files are served, with no backend required.
|
||||
When debugging network issues, it's useful to have a persistent at-a-glance view
|
||||
of latency and reachability to multiple well-known internet endpoints. NetWatch
|
||||
provides this as a zero-dependency SPA that can be deployed anywhere static
|
||||
files are served, with no backend required.
|
||||
|
||||
## Design
|
||||
|
||||
The application is a single-page app built with Vite and Tailwind CSS v4. All code lives in `src/main.js` with a class-based architecture:
|
||||
The application is a single-page app built with Vite and Tailwind CSS v4. All
|
||||
code lives in `src/main.js` with a class-based architecture:
|
||||
|
||||
- **`CONFIG`**: Frozen configuration object (update interval, timeouts, axis ticks, etc.)
|
||||
- **`HostState`**: Per-host state management — history buffer, latency tracking, status transitions
|
||||
- **`AppState`**: Top-level state container — WAN hosts, local hosts, pause state, aggregate stats
|
||||
- **`SparklineRenderer`**: Canvas 2D sparkline drawing with fixed axes, color-coded line segments, error regions, and DPR-aware scaling
|
||||
- **UI functions**: `buildUI()` constructs the DOM, `updateHostRow()` / `updateSummary()` / `updateHealthBox()` handle incremental updates
|
||||
- **`tick()`**: Main loop — measures all hosts in parallel via `Promise.all`, pushes samples, redraws UI. When paused, pushes blank markers (no probes, no false outage)
|
||||
- **`CONFIG`**: Frozen configuration object (update interval, timeouts, axis
|
||||
ticks, etc.)
|
||||
- **`HostState`**: Per-host state management — history buffer, latency tracking,
|
||||
status transitions
|
||||
- **`AppState`**: Top-level state container — WAN hosts, local hosts, pause
|
||||
state, aggregate stats
|
||||
- **`SparklineRenderer`**: Canvas 2D sparkline drawing with fixed axes,
|
||||
color-coded line segments, error regions, and DPR-aware scaling
|
||||
- **UI functions**: `buildUI()` constructs the DOM, `updateHostRow()` /
|
||||
`updateSummary()` / `updateHealthBox()` handle incremental updates
|
||||
- **`tick()`**: Main loop — measures all hosts in parallel via `Promise.all`,
|
||||
pushes samples, redraws UI. When paused, pushes blank markers (no probes, no
|
||||
false outage)
|
||||
|
||||
### Monitoring targets
|
||||
|
||||
- **9 WAN hosts**: Google Cloud Console, AWS Console, GitHub, Cloudflare, Azure, DigitalOcean, Fastly, Akamai, datavi.be
|
||||
- **1 Local host**: Local Gateway (192.168.100.1), tracked separately from WAN stats
|
||||
- **9 WAN hosts**: Google Cloud Console, AWS Console, GitHub, Cloudflare, Azure,
|
||||
DigitalOcean, Fastly, Akamai, datavi.be
|
||||
- **1 Local host**: Local Gateway (192.168.100.1), tracked separately from WAN
|
||||
stats
|
||||
|
||||
### Latency measurement
|
||||
|
||||
HEAD requests with `mode: 'no-cors'` and `cache: 'no-store'`, timed with `performance.now()`. 1-second timeout; anything over 1000ms is clamped to unreachable. IPv4 only.
|
||||
HEAD requests with `mode: 'no-cors'` and `cache: 'no-store'`, timed with
|
||||
`performance.now()`. 1-second timeout; anything over 1000ms is clamped to
|
||||
unreachable. IPv4 only.
|
||||
|
||||
### Color coding
|
||||
|
||||
@ -72,31 +90,40 @@ dist/
|
||||
- Summary stats: reachable count, min/max/avg latency across WAN hosts only
|
||||
- Fixed chart axes: Y-axis 0–1000ms, X-axis 0–300s
|
||||
- Color-coded latency figures and sparkline line segments
|
||||
- Play/pause: pause stops probes but history keeps scrolling (blank gaps, no false outage)
|
||||
- Play/pause: pause stops probes but history keeps scrolling (blank gaps, no
|
||||
false outage)
|
||||
- Clickable service URLs
|
||||
- Canvas-based sparkline rendering with devicePixelRatio scaling
|
||||
- Zero runtime dependencies: all resources bundled into build artifacts
|
||||
|
||||
## Deployment
|
||||
|
||||
After running `yarn build`, deploy the contents of the `dist/` directory to any static file host (S3, GCS, Cloudflare Pages, Vercel, Netlify, GitHub Pages) or use the Docker image behind a reverse proxy.
|
||||
After running `yarn build`, deploy the contents of the `dist/` directory to any
|
||||
static file host (S3, GCS, Cloudflare Pages, Vercel, Netlify, GitHub Pages) or
|
||||
use the Docker image behind a reverse proxy.
|
||||
|
||||
The Docker image:
|
||||
|
||||
- Listens on port 8080 by default (override with `PORT` env var)
|
||||
- Trusts `X-Forwarded-For` from RFC1918 reverse proxies (10/8, 172.16/12, 192.168/16)
|
||||
- Trusts `X-Forwarded-For` from RFC1918 reverse proxies (10/8, 172.16/12,
|
||||
192.168/16)
|
||||
- Sends access logs to stdout
|
||||
- Caches static assets with immutable headers
|
||||
|
||||
## Browser Compatibility
|
||||
|
||||
Requires a modern browser with ES modules, Fetch API, Canvas API, and CSS custom properties.
|
||||
Requires a modern browser with ES modules, Fetch API, Canvas API, and CSS custom
|
||||
properties.
|
||||
|
||||
## Limitations
|
||||
|
||||
- **CORS**: Some hosts may block cross-origin HEAD requests. The app uses `no-cors` mode which allows the request but provides opaque responses. Latency is still measurable based on request timing.
|
||||
- **Local gateway**: The 192.168.100.1 endpoint requires the host to be accessible from your network.
|
||||
- **Network conditions**: Measurements reflect browser-to-endpoint latency, which includes your local network, ISP, and internet routing.
|
||||
- **CORS**: Some hosts may block cross-origin HEAD requests. The app uses
|
||||
`no-cors` mode which allows the request but provides opaque responses. Latency
|
||||
is still measurable based on request timing.
|
||||
- **Local gateway**: The 192.168.100.1 endpoint requires the host to be
|
||||
accessible from your network.
|
||||
- **Network conditions**: Measurements reflect browser-to-endpoint latency,
|
||||
which includes your local network, ISP, and internet routing.
|
||||
|
||||
## TODO
|
||||
|
||||
|
||||
@ -1,23 +1,22 @@
|
||||
# Development Policies
|
||||
|
||||
- Docker image references by tag are server-mutable, therefore using them is
|
||||
an RCE vulnerability. All docker image references must use cryptographic
|
||||
hashes to securely specify the exact image that is expected.
|
||||
- Docker image references by tag are server-mutable, therefore using them is an
|
||||
RCE vulnerability. All docker image references must use cryptographic hashes
|
||||
to securely specify the exact image that is expected.
|
||||
|
||||
- Correspondingly, `go install` commands using things like '@latest' are
|
||||
also dangerous RCE. Whenever writing scripts or tools, ALWAYS specify go
|
||||
install targets using commit hashes which are cryptographically secure.
|
||||
- Correspondingly, `go install` commands using things like '@latest' are also
|
||||
dangerous RCE. Whenever writing scripts or tools, ALWAYS specify go install
|
||||
targets using commit hashes which are cryptographically secure.
|
||||
|
||||
- Every repo with software in it must have a Makefile in the root. Each
|
||||
such Makefile should support `make test` (runs the project-specific
|
||||
tests), `make lint`, `make fmt` (writes), `make fmt-check` (readonly), and
|
||||
`make check` (has `test`, `lint`, and `fmt-check` as prereqs), `make
|
||||
docker` (builds docker image).
|
||||
- Every repo with software in it must have a Makefile in the root. Each such
|
||||
Makefile should support `make test` (runs the project-specific tests),
|
||||
`make lint`, `make fmt` (writes), `make fmt-check` (readonly), and
|
||||
`make check` (has `test`, `lint`, and `fmt-check` as prereqs), `make docker`
|
||||
(builds docker image).
|
||||
|
||||
- Every repo should have a Dockerfile. If the repo contains non-server
|
||||
software, the Dockerfile should bring up a development environment and
|
||||
`make check` (i.e. the docker build should fail if the branch is not
|
||||
green).
|
||||
- Every repo should have a Dockerfile. If the repo contains non-server software,
|
||||
the Dockerfile should bring up a development environment and `make check`
|
||||
(i.e. the docker build should fail if the branch is not green).
|
||||
|
||||
- Platform-specific standard formatting should be used. `black` for python,
|
||||
`prettier` for js/css/etc, `go fmt` for go. The only changes to default
|
||||
@ -25,27 +24,27 @@ docker` (builds docker image).
|
||||
everything except `go fmt`).
|
||||
|
||||
- If local testing is possible (it is not always), `make check` should be a
|
||||
pre-commit hook. If it is not possible, `make lint && make fmt-check`
|
||||
should be a pre-commit hook.
|
||||
pre-commit hook. If it is not possible, `make lint && make fmt-check` should
|
||||
be a pre-commit hook.
|
||||
|
||||
- If a working `make test` takes more than 20 seconds, that's a bug that
|
||||
needs fixing. In fact, there should be a timeout specified in the
|
||||
`Makefile` that fails it automatically if it takes >30s.
|
||||
- If a working `make test` takes more than 20 seconds, that's a bug that needs
|
||||
fixing. In fact, there should be a timeout specified in the `Makefile` that
|
||||
fails it automatically if it takes >30s.
|
||||
|
||||
- Docker builds should time out in 5 minutes or less.
|
||||
|
||||
- `main` must always pass `make check`, no exceptions.
|
||||
|
||||
- Do all changes on a feature branch. You can do whatever you want on a
|
||||
feature branch.
|
||||
- Do all changes on a feature branch. You can do whatever you want on a feature
|
||||
branch.
|
||||
|
||||
- We have a standardized `.golangci.yml` which we reuse and is _NEVER_ to be
|
||||
modified by an agent, only manually by the user. It can be copied from
|
||||
`~/dev/upaas/.golangci.yml` if it exists at that location.
|
||||
|
||||
- When specifying images or packages by hash in Dockerfiles or
|
||||
`docker-compose.yml`, put a comment above the line and show the version
|
||||
and date at which it was current.
|
||||
`docker-compose.yml`, put a comment above the line and show the version and
|
||||
date at which it was current.
|
||||
|
||||
- For javascript, always use `yarn` over `npm`.
|
||||
|
||||
@ -54,11 +53,11 @@ docker` (builds docker image).
|
||||
- Simple projects should be configured with environment variables, as is
|
||||
standard for Dockerized applications.
|
||||
|
||||
- Dockerized web services should listen on the default HTTP port of 8080
|
||||
unless overridden with the `PORT` environment variable.
|
||||
- Dockerized web services should listen on the default HTTP port of 8080 unless
|
||||
overridden with the `PORT` environment variable.
|
||||
|
||||
- The `README.md` is a project's primary documentation. It should contain
|
||||
at a minimum the following sections:
|
||||
- The `README.md` is a project's primary documentation. It should contain at a
|
||||
minimum the following sections:
|
||||
- Description
|
||||
- Include a short and complete description of the functionality and
|
||||
purpose of the software as the first line in the readme. It must
|
||||
@ -68,10 +67,10 @@ docker` (builds docker image).
|
||||
- the category (web server, SPA, command line tool, etc)
|
||||
- the license
|
||||
- the author
|
||||
- eg: "µPaaS is an MIT-licensed Go web application by @sneak
|
||||
that receives git-frontend webhooks and interacts with a
|
||||
Docker server to build and deploy applications in realtime as
|
||||
certain branches are updated."
|
||||
- eg: "µPaaS is an MIT-licensed Go web application by @sneak that
|
||||
receives git-frontend webhooks and interacts with a Docker server
|
||||
to build and deploy applications in realtime as certain branches
|
||||
are updated."
|
||||
- Getting Started
|
||||
- a code block with copy-pasteable installation/use sections
|
||||
- Rationale
|
||||
@ -79,28 +78,27 @@ docker` (builds docker image).
|
||||
- Design
|
||||
- how is the program structured?
|
||||
- TODO
|
||||
- This is your TODO list for the project - update it meticulously,
|
||||
even in between commits. Whenever planning, put your todo list in
|
||||
the README so that a separate agent with new context can pick up
|
||||
where you left off.
|
||||
- This is your TODO list for the project - update it meticulously, even
|
||||
in between commits. Whenever planning, put your todo list in the
|
||||
README so that a separate agent with new context can pick up where you
|
||||
left off.
|
||||
- License
|
||||
- GPL or MIT or WTFPL - ask the user when beginning a new project
|
||||
and include a LICENSE file in the root and in a section in the
|
||||
README.
|
||||
- GPL or MIT or WTFPL - ask the user when beginning a new project and
|
||||
include a LICENSE file in the root and in a section in the README.
|
||||
- Author
|
||||
- @sneak (link `@sneak` to `https://sneak.berlin`).
|
||||
|
||||
- When beginning a new project, initialize a git repo and make the first
|
||||
commit simply the first version of the README.md in the root of the repo.
|
||||
- When beginning a new project, initialize a git repo and make the first commit
|
||||
simply the first version of the README.md in the root of the repo.
|
||||
|
||||
- For Go packages, the module root is `sneak.berlin/go/...`, such
|
||||
as `sneak.berlin/go/dnswatcher`.
|
||||
- For Go packages, the module root is `sneak.berlin/go/...`, such as
|
||||
`sneak.berlin/go/dnswatcher`.
|
||||
|
||||
- We use SemVer always.
|
||||
|
||||
- If no tag `1.0.0` or greater exists in the repository, modify the existing
|
||||
migrations and assume no installed base or existing databases. If
|
||||
`>=1.0.0`, database changes add new migration files.
|
||||
migrations and assume no installed base or existing databases. If `>=1.0.0`,
|
||||
database changes add new migration files.
|
||||
|
||||
- New repos must have at a minimum the following files:
|
||||
- `README.md`, `.git`, `.gitignore`
|
||||
|
||||
Loading…
Reference in New Issue
Block a user