You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Take a look at the [documentation](https://accenture.github.io/reactive-interaction-gateway/docs/intro.html) and get in touch with us on [Slack](https://rig-slackin.herokuapp.com)!
11
-
12
10
## About
13
11
14
12
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)
@@ -22,7 +20,7 @@ The Reactive Interaction Gateway (RIG) is the glue between your client (frontend
22
20
23
21
Built on open standards, RIG is very easy to integrate – and easy to replace – which means low-cost, low-risk adoption. Unlike other solutions, RIG does not leak into your application – no libraries or SDKs required. Along with handling client requests and publishing events from backend to the frontend, RIG provides [many built-in features](https://accenture.github.io/reactive-interaction-gateway/docs/features.html#built-in-features).
24
22
25
-
Learn more by taking a look into the [documentation](https://accenture.github.io/reactive-interaction-gateway/docs/intro.html) and the [FAQ](https://accenture.github.io/reactive-interaction-gateway/docs/faq.html).
23
+
This is just a basic summary of what RIG can do. There is a comprehensive documentation available on our [website](https://accenture.github.io/reactive-interaction-gateway/docs/intro.html). If you have any unanswered question, check out the [FAQ](https://accenture.github.io/reactive-interaction-gateway/docs/faq.html) section to get them answered.
RIG is able to process distributed tracing data following the [W3C Trace Contexts](https://www.w3.org/TR/trace-context/).
8
8
9
-
In certain conditions RIG expects the trace context to be in the (HTTP) Header, and in other conditions in the event payload itself. With events, we always speak of cloudevents following the [distributed tracing extension](https://github.com/cloudevents/spec/blob/v1.0/extensions/distributed-tracing.md). There is one key rule when RIG expects the trace context either in the header or in the cloudevent:
9
+
In certain conditions RIG expects the trace context to be in the (HTTP) header, and in other conditions in the event payload itself. With events, we always speak of cloudevents following the [distributed tracing extension](https://github.com/cloudevents/spec/blob/v1.0/extensions/distributed-tracing.md). There is one key rule when RIG expects the trace context either in the header or in the cloudevent:
10
10
11
11
1. if we talk of messages, then RIG expects the trace context to be in the (HTTP) header
12
12
2. if we talk of events (cloudevents), then RIG expects the trace context to be in the cloudevent
You may ask: Why shouldn't I directly talk to the Backend? What benefits does RIG provide?
37
+
You may ask: Why shouldn't I directly talk to the backend? What benefits does RIG provide?
38
38
39
-
Rig provides many additional features on top like session management or JWT signature verification. You don't have to implement this over and over again at the clients and backend services.
39
+
RIG provides many additional features on top like session management or JWT signature verification. You don't have to implement this over and over again at the clients and backend services.
40
40
41
41
### Asynchronously - Fire&Forget
42
42
@@ -52,7 +52,7 @@ RIG forwards the client request to the backend synchronously via HTTP and waits
This scenario can be quite useful which is described in more detail in the [Architecture section](https://accenture.github.io/reactive-interaction-gateway/docs/architecture.html#providing-a-synchronous-api-for-asynchronous-back-end-services). RIG correlates the corresponding answer using the correlation ID of the original request, that will be forwarded to the backend and also being used in the response of the backend. With this ID, RIG can filter the appropriate message from the consuming topic.
55
+
This scenario can be quite useful which is described in more detail in the [Architecture section](https://accenture.github.io/reactive-interaction-gateway/docs/architecture.html#providing-a-synchronous-api-for-asynchronous-back-end-services). RIG correlates the corresponding answer using the correlation ID of the oRIGinal request, that will be forwarded to the backend and also being used in the response of the backend. With this ID, RIG can filter the appropriate message from the consuming topic.
56
56
57
57
As you can see in the architecture diagram, the backend service responds to RIG with `202 Accepted` to tell RIG that the response will be provided asynchronously.
58
58
@@ -71,19 +71,19 @@ Essentially this is a combination of the [asynchronous - fire&forget approach](#
71
71
Built on open standards, RIG is very easy to integrate – and easy to replace – which means low-cost, low-risk adoption. Unlike other solutions, RIG does not leak into your application – no libraries or SDKs required. Along with handling client requests and publishing events from backend to the frontend, RIG provides many built-in features such as:
72
72
73
73
- Easy to use and scalable by design:
74
-
- Supports tens of thousands stable connections per node even on low-end machines.
75
-
- Easy to add additional nodes.
76
-
- Built on the battle-proven [Erlang/OTP](http://www.erlang.org/) distribution model.
77
-
- Only uses in-memory data structures - no external dependencies to configure or scale.
74
+
- Supports tens of thousands stable connections per node even on low-end machines
75
+
- Easy to add additional nodes
76
+
- Built on the battle-proven [Erlang/OTP](http://www.erlang.org/) distribution model
77
+
- Only uses in-memory data structures - no external dependencies to configure or scale
78
78
- Connect using standard protocols:
79
79
- Firewall friendly and future proof using Server-Sent Events (SSE)
0 commit comments