mirror of
https://github.com/avatao-content/baseimage-tutorial-framework
synced 2024-11-01 00:31:22 +00:00
Update README and explain TFW server behaviour better
This commit is contained in:
parent
57d2475ebc
commit
5262401b18
27
README.md
27
README.md
@ -20,6 +20,20 @@ Frontend components use websockets to connect to the TFW server, to which you ca
|
|||||||
|
|
||||||
![TFW architecture](docs/tfw_architecture.png)
|
![TFW architecture](docs/tfw_architecture.png)
|
||||||
|
|
||||||
|
### Networking details
|
||||||
|
|
||||||
|
Event handlers connect to the TFW server using ZMQ.
|
||||||
|
They receive messages on their `SUB`(scribe) sockets, which are connected to the `PUB`(lish) socket of the server.
|
||||||
|
Event handlers reply on their `PUSH` socket, then their messages are received on the `PULL` socket of the server.
|
||||||
|
|
||||||
|
The TFW server is basically just a fancy proxy.
|
||||||
|
It's behaviour is quite simple: it proxies every message received from the fontend to the event handlers and vice versa.
|
||||||
|
|
||||||
|
The server is also capable of "mirroring" messages back to their source.
|
||||||
|
This is useful for communication between event handlers or frontend components (event handler to event handler or frontend component to frontend component communication).
|
||||||
|
|
||||||
|
Components can also broadcast messages (broadcasted messages are received both by event handlers and the frontend as well).
|
||||||
|
|
||||||
### Event handlers
|
### Event handlers
|
||||||
|
|
||||||
Imagine event handlers as callbacks that are invoked when TFW receives a specific type of message. For instance, you could send a message to the framework when the user does something of note.
|
Imagine event handlers as callbacks that are invoked when TFW receives a specific type of message. For instance, you could send a message to the framework when the user does something of note.
|
||||||
@ -75,6 +89,19 @@ The TFW message format:
|
|||||||
- The `data` object can contain anything you might want to send
|
- The `data` object can contain anything you might want to send
|
||||||
- The `trigger` key is an optional field that triggers an FSM action with that name from the current state (whatever that might be)
|
- The `trigger` key is an optional field that triggers an FSM action with that name from the current state (whatever that might be)
|
||||||
|
|
||||||
|
To mirror messages back to their sources you can use a special messaging format, in which the message to be mirrored is enveloped inside the `data` field of the outer message:
|
||||||
|
|
||||||
|
```text
|
||||||
|
"key": "mirror",
|
||||||
|
"data":
|
||||||
|
{
|
||||||
|
...
|
||||||
|
The message you want to mirror (with it's own "key" and "data" fields)
|
||||||
|
...
|
||||||
|
}
|
||||||
|
```
|
||||||
|
|
||||||
|
Broadcasting messages is possible in a similar manner by using `"key": "broadcast"` in the outer message.
|
||||||
|
|
||||||
## Where to go next
|
## Where to go next
|
||||||
|
|
||||||
|
Binary file not shown.
Before Width: | Height: | Size: 40 KiB After Width: | Height: | Size: 46 KiB |
Loading…
Reference in New Issue
Block a user