gui-thunks VS c4-notation

It's interesting how every build system, frontend framework, programming language implements its own promise pipeline/delayed execution/observables/event propagation.

But the implementations are rarely extracted out for general purpose usage and rarely have a rich API.

I've been thinking a lot about a general purpose "epoll" which be registered on objects that change. I want to be able to register a reaction to a sequence of actions on arbitrary objects with an epoll style API.

One of my ideas is GUI thunking. The idea that every interaction with the GUI raises a new type that can be interacted with, to queue up behaviours on the GUI. This is essentially Future<> that are typed and the system reacts to the new type based on what you did.

It's a bit like terraform plan and apply, but applied to general purpose GUIs.

For example, you can click download file, then queue up installation and then using the application, ALL BEFORE it is installed. Because the actual computation is separate from the type information that was queued up.

Imagine using AWS Console to set up an entire infrastructure and wire everything together but not actually execute anything until the very end when you click "Run".

https://github.com/samsquire/gui-thunks

I spend everyday thinking of what my computer could be doing.

Most of the time the CPU is waiting for IO - memory, network, SSD, disk and not doing any work.

You might like my idea called GUI Thunking.

https://github.com/samsquire/gui-thunks

Second this.

Reference for anyone looking I to it: https://c4model.com/

There is also quite a lot of options for helping create these diagrams. I've found https://structurizr.com/ to be the best of what I've tried so far.

What you are describing sounds a lot like C4: https://c4model.com/

The C4 model [0] provides a mostly sensible structure and techniques for representing pure software systems across different abstraction levels.

For systems involving software and hardware, or other complex interfacing (both technology and bureaucracy) this starts to delve into the universe of systems engineering. There's a decent assembly of knowledge on that in the SEBoK [1].

As another commenter has already called out too, one of the most valuable sources of information is also _why_ a system is in its current form and _how_ that's changed over time. ADR's [2] really do a good job at nailing this for just about any scale.

[0]: https://c4model.com

[1]: https://sebokwiki.org

[2]: https://adr.github.io

There a various standards for documenting software architecture, like arc42 or C4. While useful and somewhat well-known (there is certainly a correlation here), here architecture documentation can be further simplified, particularly due to the self-similarity of project and component. Following is a small template, that can also serve as a project's and component's README:

I would suggest that if your architecture diagrams are a bunch of icons provided by AWS/Azure/GCP with lines pointing at each other... you are doing it wrong.

The 'what does this box do for my system' is vastly more important than the 'which in vogue offering from my cloud provider implements it'.

I highly suggest folks take a look at the C4 Model: https://c4model.com/

We often use abstractions in software engineering to communicate complex architectures and software systems. In this article, we’ll discuss how abstractions are inherently hierarchical and how the C4 model provides a nested structure for defining your software architecture. We’ll then cover how IcePanel allows you to create interactive and zoomable diagrams for your audience to zoom in and out of different levels of technical detail.

You probably want https://c4model.com/ which explains what a C4 architecture diagram is. (See the first footnote in the article.)