document forwarding backend events to RIG directly without a message broker

Author: Knappek

README.md

@@ -11,7 +11,9 @@ Makes frontend<->backend communication reactive and event-driven.
 
 The Reactive Interaction Gateway (RIG) is the glue between your client (frontend) and your backend. It makes communication between them easier by (click the links to learn more)
 
-- [picking up backend events and forwarding them to clients based on subscriptions](https://accenture.github.io/reactive-interaction-gateway/docs/features.html#picking-up-backend-events-and-forwarding-them-to-clients-based-on-subscriptions): this makes your frontend apps **reactive and eliminates the need for polling**.
+- picking up backend events and forwarding them to clients based on subscriptions: this makes your frontend apps **reactive and eliminates the need for polling**. You can do this
+  - [asynchronously](https://accenture.github.io/reactive-interaction-gateway/docs/features.html#picking-up-backend-events-and-forwarding-them-to-clients-based-on-subscriptions#asynchronously) using Kafka, Nats or Kinesis.
+  - [synchronously](https://accenture.github.io/reactive-interaction-gateway/docs/features.html#picking-up-backend-events-and-forwarding-them-to-clients-based-on-subscriptions#synchronously) if you don't want to manage a (potentially complex) message broker system like Kafka.
 - forwarding client requests to backend services either synchronously, asynchronously or a mix of both:
   - [synchronously](https://accenture.github.io/reactive-interaction-gateway/docs/features.html#synchronously): if requests are being sent synchronously, RIG acts as a reverse proxy: RIG forwards the request to an HTTP endpoint of a backend service, waits for the response and sends it to the client.
   - [asynchronously - fire&forget](https://accenture.github.io/reactive-interaction-gateway/docs/features.html#asynchronously---fireforget): RIG transforms a HTTP request to a message for asynchronous processing and forwards it to the backend asynchronously using either Kafka, NATS or Amazon Kinesis.

docs/assets/drawio/features-fan-out-to-multiple-clients-synchronously.drawio

@@ -5,8 +5,10 @@ sidebar_label: Features
 ---
 
 * [Picking up backend events and forwarding them to clients based on subscriptions](#picking-up-backend-events-and-forwarding-them-to-clients-based-on-subscriptions)
-* [Forwarding client requests to backend services](#forwarding-client-requests-to-backend-services)
+  * [Asynchronously](#asynchronously)
   * [Synchronously](#synchronously)
+* [Forwarding client requests to backend services](#forwarding-client-requests-to-backend-services)
+  * [Synchronously](#synchronously-1)
   * [Asynchronously - Fire&Forget](#asynchronously---fireforget)
   * [Synchronously - Asnychronous Response](#synchronously---asnychronous-response)
   * [Asynchronously - Asnychronous Response](#asynchronously---asnychronous-response)
@@ -16,6 +18,8 @@ RIG can be used in different scenarios.
 
 ## Picking up backend events and forwarding them to clients based on subscriptions
 
+### Asynchronously
+
 RIG acts as a fan-out publisher of backend events. Clients can simply subscribe to RIG in order to receive these events. This makes your frontend apps reactive and eliminates the need for polling.
 
 Additionally clients can provide filters during the subscription initialization and tell RIG in what type of events it is interested in. Those filters allow clients to tap into high-volume event streams without getting overwhelmed by unwanted events. In other words, filters enable bandwidth efficiency.
@@ -24,6 +28,12 @@ Additionally clients can provide filters during the subscription initialization
 
 ![fan-out-to-multiple-clients](./assets/features-fan-out-to-multiple-clients.png)
 
+### Synchronously
+
+With RIG, you don't have to necessarily deploy and manage Kafka/Nats/Kinesis. In the previous architecture you can simply remove that part and publish events from the backend directly to RIG. RIG then acts as a simple message broker:
+
+![fan-out-to-multiple-clients-synchronously](./assets/features-fan-out-to-multiple-clients-synchronously.png)
+
 ## Forwarding client requests to backend services
 
 When client requests need to be forwarded to the backend, clients sometimes are interested in the response of the backend, and sometimes not. Especially when the client is interested in the direct response of the backend, there are a couple of options how to design that technically.