View Source PlausibleWeb.StatsController (Plausible v0.0.1)

This controller is responsible for rendering stats dashboards.

The stats dashboards are currently the only part of the app that uses client-side rendering. Since the dashboards are heavily interactive, they are built with React which is an appropriate choice for highly interactive browser UIs.

sequenceDiagram Browser->>StatsController: GET /mydomain.com StatsController-->>Browser: StatsView.render("stats.html") Note left of Browser: ReactDom.render(Dashboard) Browser -) Api.StatsController: GET /api/stats/mydomain.com/top-stats Api.StatsController --) Browser: {"top_stats": [...]} Note left of Browser: TopStats.render() Browser -) Api.StatsController: GET /api/stats/mydomain.com/main-graph Api.StatsController --) Browser: [{"plot": [...], "labels": [...]}, ...] Note left of Browser: VisitorGraph.render() Browser -) Api.StatsController: GET /api/stats/mydomain.com/sources Api.StatsController --) Browser: [{"name": "Google", "visitors": 292150}, ...] Note left of Browser: Sources.render() Note over Browser,StatsController: And so on, for all reports in the viewport

This reasoning for this sequence is as follows:

First paint is fast because it doesn't do any data aggregation yet - good UX
The basic structure of the dashboard is rendered with spinners before reports are ready - good UX
Rendering on the frontend allows for maximum interactivity. Re-rendering and re-fetching can be as granular as needed.
Routing on the frontend allows the user to navigate the dashboard without reloading the page and losing context
Rendering on the frontend allows caching results in the browser to reduce pressure on backends and storage 3.1 No client-side caching has been implemented yet. This is still theoretical. See https://github.com/plausible/analytics/discussions/1278 3.2 This is a big potential opportunity, because analytics data is mostly immutable. Clients can cache all historical data.
Since frontend rendering & navigation is harder to build and maintain than regular server-rendered HTML, we don't use SPA-style rendering anywhere else .The only place currently where the benefits outweigh the costs is the dashboard.

Summary

Functions

authenticate_shared_link(conn, map)

csv_export(conn, params)

The export is limited to 300 entries for other reports and 100 entries for pages because bigger result sets start causing failures. Since we request data like time on page or bounce_rate for pages in a separate query using the IN filter, it causes the requests to balloon in payload size.

shared_link(conn, arg2)

Authorizes and renders a shared link

stats(conn, params)

Functions

authenticate_shared_link(conn, map)

csv_export(conn, params)

shared_link(conn, arg2)

Authorizes and renders a shared link:

Shared link with no password protection: needs to just make sure the shared link entry is still in our database. This check makes sure shared link access can be revoked by the site admins. If the shared link exists, render it directly.
Shared link with password protection: Same checks as without the password, but an extra step is taken to protect the page with a password. When the user passes the password challenge, a cookie is set with Plausible.Auth.Token.sign_shared_link(). The cookie allows the user to access the dashboard for 24 hours without entering the password again.

### Backwards compatibility

The URL format for shared links was changed in this pull request in order to make the URLs easier to bookmark. The old format is supported along with the new in order to not break old links.

See: https://plausible.io/docs/shared-links

Settings View Source PlausibleWeb.StatsController (Plausible v0.0.1)

Summary

Functions

Functions

authenticate_shared_link(conn, map)

csv_export(conn, params)

shared_link(conn, arg2)

stats(conn, params)

View Source PlausibleWeb.StatsController (Plausible v0.0.1)