Basic Web UI for Ratman

Issue Fix

Part of #50 (closed)

Description

This adds an Ember.js-based Web UI to ratmand, replicating 1:1 the current format string based one as a proof-of-concept. It's powered by a simple REST API running on the same port, currently containing only one endpoint:

$ http localhost:8090/v1/addrs
HTTP/1.1 200 OK
content-length: 326
content-type: application/json
date: Tue, 29 Mar 2022 09:42:08 GMT

{
    "addrs": [
        {
            "id": "2AE3-D6CB-3FA4-CD8D-22F4-5E12-74CD-516E-1FB7-A1C0-8436-2837-7E09-D467-ED30-99C3",
            "is_local": true
        },
        {
            "id": "43CC-8612-0100-E6CD-F06A-1049-948E-3DA3-94B8-3E7B-C131-BA1D-2570-2D1B-4C2D-A2CA",
            "is_local": true
        },
        {
            "id": "7D47-AE70-ECFF-D921-8EDA-1B1F-1D9F-4017-1A9F-6F41-71A3-E411-F3C0-FA54-315D-E95E",
            "is_local": true
        }
    ]
}

The assets for the UI are ~250kb of HTML, JS and CSS files, most of which is overhead from Ember.js itself, and are embedded in the binary itself.

This comes with the small caveat that building ratmand with --feature=webui will fail if the /ratman/dashboard/dist/ directory doesn't exist - although if it didn't, it would be possible to produce a binary with a broken web UI. Anyone who really wants to build it without a functioning UI (eg. for development) can simply create an empty directory at that path.

Alternative(s) considered

Ember.js was chosen after some discussion on Matrix, mainly on the basis that:

1. Both myself (@embr) and @lux are familiar with it already.
2. It's been around for over a decade, and has consistently prioritised stable APIs, making improvements under the hood where possible, and where not, gracefully deprecating old APIs and offering clear migration paths (example). We're not worried about it disappearing or breaking anytime soon.
3. It has a great name tbh

The API response format is fairly standard; we did discuss implementing JSON-API, but decided that it's way overkill for the scope of this. Versioning your API (/v1/...) is just good practice, even if you never need a v2.

Type

Feature

Screenshots (if applicable)

It looks exactly like the existing web UI, but it's rendered on the client side: