# Jan 23

### Connecting Clients to reactors

**Client -> Server -> Reactor**

I can take advantage of the private network created via wireguard to allow the server to connected back to individual reactors and then intiate gRPC calls.

**Pros**
- This *VASTLY* simplifies the implementation as I can now connect back to the reactors themselves
    - from there, I can implement various functions I will need server side
        - i.e. GetName() SetName() etc.

**Cons**
- I will eventually need to build the wiregaurd implementation
    - although because its all local network for now, I can plug and play down the road

### TODO
- refactor packages to provide a cleaner interface via simple commands as opposed to the convoluted passing structure that was present with the old I2C library
- start working on the interface between the websocket and the reactor
    - react side this is the actual content that will be rendered by the client
    - server side this will be a connection to a reactor with the gRPC calls
- moving monitoring functionality to the reactor
    - refactoring to use streaming functionality to avoid needing to re initiate request
    - have server connect each reactor manager to the rlc
    - have the reactor manager ping for server info
        - handle disconnects via exit
    - sets up cleaner device handling via multiplexing

# Jan 24

### Proto changes

It's time to refactor the current protobuf stuff to make more sense from the servers perspective. In this sense, I am going to have the reactor provide connection details to the server on connect, and then the server can connect/disconnect at will.

### Outline
- Update the server to connect to the reactor itself for the information
- Decide what information is important enough to send to the server consistently, vs what only is needed upon "further inspection"
    - need reactor information on connect
    - need basic device information such as address and status
    - when selected
        - need specific device breakouts with advanced functions per device
        - this can be multiplexed over the same gRPC connection and can be fulfilled by the device coordinator
            - dc will catch all incoming requests and forward to the correct DM based on address

### TODO
- reverse monitoring stuff
    - make it so reactor manager has a timeout/ recognizes disconnects gracefully
    - convert monitoring to a stream as opposed to consistent calls