ws-monitoring VS hof

ws-monitoring

Shameless plug,I made a lightweight real time monitoring tools using websockets, it's open source: https://github.com/elestio/ws-monitoring/

Here is my half baked real-time server monitoring system: https://github.com/elestio/ws-monitoring

It's a web UI + websocket backend, very small, 10kb vanilla frontend and 300 LOC for the backend.

My goal is not to compete with netdata or other big tools but serve my own needs using really few resources

Yea, in particular for this project, they have created a bespoke templating system.

You can get the same thing with Go text/templates by adding chat function(s) as custom a helper: https://github.com/hofstadter-io/hof/blob/_dev/lib/templates...

100% one of the best things about building a TUI is not having the pain of modern web development. I do think there is a way to have a CLI & TUI come from the same code, so you can get the best of both, or pick the best for the task at hand.

experiments in progress here: https://github.com/hofstadter-io/hof/tree/_dev/lib/tui

CUE is another interesting language to use from within Go, and is rather natural, given CUE is implemented in Go, but you can also do way more cool things with CUE via the Go API.

We're using CUE to validate and transform data, as input to code gen, the basis for a DAG task engine, and more

https://cuelang.org | https://pkg.go.dev/cuelang.org/[email protected]/cue | https://cuetorials.com/go-api (learn about CUE)

https://github.com/hofstadter-io/hof (where we are doing these things)

here is one of our early examples: https://github.com/hofstadter-io/hof/blob/_dev/flow/chat/pro...

declarative code generation https://github.com/hofstadter-io/hof because I was tired of having to change 10+ files in a full stack app to add a field to one type, so I brought ideas from devops to application development

it's now generalized and for everyone

I build https://github.com/hofstadter-io/hof

I think I prefer our create workflow (https://docs.hofstadter.io/getting-started/create/)

Far more flexible than GHT and works from anywhere. It would be interesting to see your project as a hof creator. Similar things are on the endless examples todo list... :]

Check out my project https://docs.hofstadter.io

This was a core tenant of the code generation. Additionally, you can also edit the output fields and still keep support for regeneration after template updates.

I've been thinking about this from a slightly different angle (https://github.com/hofstadter-io/hof), but I think we are both getting at a higher level of reuse and dependency management. I just don't think we need to limit the idea to APIs, there are different granularities, both bigger and smaller, where the ideas are useful.

https://github.com/hofstadter-io/hof - data modeling & code gen tool, open-source and open-ecosystem. The goal is to code gen the majority (80%) of the mundane code so we only have to work on the interesting parts. You can use any language or technology.