web dashboard for the server

[Sweattypalms]

Currently, barely functional and has only placeholders. Need to add the relevant data to the GlobalState as well as allow console commands to be run from the website through websockets. Planned to use websockets through axum.
Test with --features dashboard

[Sweattypalms]

dashboard

[lynn2910]

Why use a "custom" templating system ? I see that there are data and elements that are duplicated (ex. max memory is also in configuration, last console messages are also in the page "console").

Things such as a store and services system would be beneficial from what I understand.

Is there a particular reason you don't want to use a framework such as React, VueJS, Angular, or even simpler templating systems that can build static sites ?

[Sweattypalms]

Why use a "custom" templating system ? I see that there are data and elements that are duplicated (ex. max memory is also in configuration, last console messages are also in the page "console").

Things such as a store and services system would be beneficial from what I understand.

Is there a particular reason you don't want to use a framework such as React, VueJS, Angular, or even simpler templating systems that can build static sites ?

Thanks for taking a look at this, haha.

On the Framework Choice: The goal is a "Single Binary" deployment. I don't want users to need Node.js/NPM to run the server. The dashboard is served as a single embedded HTML file (that's generated through CI/CD pipeline in the dashboard repo) baked into the Rust binary.

On the Tech Stack:
HTMX: I've included HTMX (index.html) to handle future UI interactions and lazy loading without writing client-side boilerplate.

Custom Telemetry: For the metrics (CPU/RAM) and Charts, I am currently using a WebSocket handler (in JS for now cuz idk htmx that well) instead of HTMX swaps. This gives me granular control over the ApexCharts and progress bars without sending full HTML chunks every second.

On Duplication: You are right about the redundancy. This PR is a Draft to get the underlying WebSocket infrastructure working. I'll clean up the HTML structure and refactor the duplication before merging. :)

[lynn2910]

OK, I see. That seems reasonable, but at some point it will definitely need some documentation, because it’s currently pretty hard to understand what’s going on under the hood.

What kind of contributions can be made to the dashboard?

By the way, some frameworks like Vue (it's the only I know for sure) can generate a single .html file plus separate asset files. Providing one standalone HTML file for the entire dashboard work too, although I have doubts about scalability as the dashboard grows larger (for example, embedding the favicon as base64 in the HTML is not a good idea if you have a lot of images and SVG icons, it'll give an HTML file of multiple Mo if I'm not misunderstanding it). I guess it depends on the scope.

[Sweattypalms]

OK, I see. That seems reasonable, but at some point it will definitely need some documentation, because it’s currently pretty hard to understand what’s going on under the hood.

What kind of contributions can be made to the dashboard?

By the way, some frameworks like Vue (it's the only I know for sure) can generate a single .html file plus separate asset files. Providing one standalone HTML file for the entire dashboard work too, although I have doubts about scalability as the dashboard grows larger (for example, embedding the favicon as base64 in the HTML is not a good idea if you have a lot of images and SVG icons, it'll give an HTML file of multiple Mo if I'm not misunderstanding it). I guess it depends on the scope.

I'd recommend you join our discord server: https://discord.gg/Npx5qy2H2h. Let's have a chat there. You can talk to not only me, but also other contributors of the FerrumC project!