Gateway Systems
A gateway system defines the means (such as REST, RSocket or Kafka) and main configurations for accessing backend runners through gateways.
Last updated
Core Platform
A gateway system defines the means (such as REST, RSocket or Kafka) and main configurations for accessing backend runners through gateways.
Last updated
All systems share the following settings, and additional parameters apply for the selected executor type:
Executor: Fully qualified class name for the executor responsible for communicating with this system.
Gateways: List of gateway ids which are allowed to communicate with this system.
All systems have the following parameters applicable:
logging_service
Name of the Kafka service for logging requests and responses
kafka_logging
-
request_logging_topic
Kafka topic to log requests
request_log
-
response_logging_topic
Kafka topic to log responses
response_log
-
tracking_service
Name of the Kafka service for recording tracking data
kafka_tracking
-
tracking_topic
Kafka topic to record tracking data
tracking_log
-
It is possible to define any number and type of new gateway systems with specialized configurations, and typical gateway system types deployed with Rierino are as follows:
With a specific executor (com.rierino.api.gateway.executor.RPCExecutor) this gateway system is used for communicating with RPCEventRunner instances over http or https, with the following parameters:
server.baseUrl
URL applied as the base for all channels
https://spring-runner-admin-prod
-
server.balanced
Whether executor should use client side load balancing (or use URL for direct access)
true
false
server.secure
Whether executor should use SSL
true
false
server.maxInMemorySize
Bytes limit for buffering data in memory by web client
16777216
-1
server.timeout
Milliseconds before the executor times out a request
10000
-
authenticated
Whether target runner requires authentication or not
true
false
Exposure of RPC event runner APIs through these systems have the following flow in a standard K8s set-up:
Installing a new deployment creates a private service endpoint accessible from within the K8s cluster through "http://runner-spring-[deploymentId]-service.admin-backend.svc.cluster.local:[port]".
[deploymentId] can be seen from the related deployment's screen. In case this id includes "_" character, it is replaced with "-" to comply with K8s path standards.
Default [port] is 1235, which can also be changed to another port using parameters of the deployment definition.
This endpoint should be configured as the "server.baseUrl" for the created gateway system.
All runners listed in deployment create new URL paths on this endpoint as "/api/[runnerName]".
[runnerName] is the name provided in the related deployment's definition as a mapping to a specific runner instance.
For each RPC runner in deployment, a new gateway channel should be created on the new gateway system. These channels are exposed as "/api/request/[channelId]" URL paths on API gateway, where [channelId] can be seen from the created gateway channel's screen.
With these configurations, sending requests to:
routes these requests to:
With a specific executor (com.rierino.api.gateway.executor.CRUDExecutor) this gateway system is used for communicating with CRUDEventRunner instances over http or https. Parameters used by RPCExecutor are also applicable for this executor.
Exposure of CRUD event runner APIs through these systems is similar to RPC flows and have the following flow in a standard K8s set-up:
Installing a new deployment creates a private service endpoint accessible from within the K8s cluster through "http://runner-spring-[deploymentId]-service.admin-backend.svc.cluster.local:[port]", same as the RPC API flow. In fact, it is possible to include both CRUD and RPC event runners within the same deployment package.
All runners listed in deployment create new URL paths on this endpoint as "/api/[runnerName]".
[runnerName] is the name provided in the related deployment's definition as a mapping to a specific runner instance.
For each CRUD runner in deployment, a new gateway channel should be created on the new gateway system. These channels are exposed as "/api/request/[channelId]" URL paths on API gateway, where [channelId] can be seen from the created gateway channel's screen.
With these configurations, sending requests to:
routes these requests to:
With a specific executor (com.rierino.api.gateway.executor.KafkaExecutor) this gateway system is used for communicating with runners such as SyncSamzaEventRunner and AsyncSamzaEventRunner through Kafka streams, with the following parameters:
bootstrap_servers
Default Kafka bootstrap servers
kafka.example.com:9092
-
timeout
Milliseconds before the executor times out a request
10000
-
topic_response
Kafka topic to receive responses on
response_product
-
producer.*
Any Kafka producer parameter
linger.ms=0
-
consumer.*
Any Kafka consumer parameter
group_id=store_product
-
Exposure of Samza event runner APIs through these systems have the following flow in a standard K8s set-up:
Installing a new deployment initializes its list of runners which start listening to their configured Kafka topics.
Each runner listens to a [request] topic (e.g. request_product), which is typically configured as its dedicated stream for receiving requests from the gateways.
After completing its process, the runner returns its results on a [response] topic (e.g. response_store). Multiple runners can share the same [response] topic.
Kafka topic which returns responses from target runners should be configured as "topic_response" for the created gateway system.
For each Samza runner in deployment, a new gateway channel should be created on the new gateway system with target set as the [request] topic of the related runner. These channels are exposed as "/api/request/[channelId]" URL paths on API gateway, where [channelId] can be seen from the created gateway channel's screen.
With these configurations, sending requests to:
routes these requests to:
With a specific executor (com.rierino.api.gateway.executor.RSocketExecutor) this gateway system is used for communicating with RSocketEventRunner instances over different protocols.
Different parameters are applicable for different connection types / protocols, with the following shared ones:
server.balanced
Whether the executor uses client side load balancing
true
false
server.protocol
Protocol to use for connection
tcp
websocket
server.retryAttempts
Number of retry attempts before failing socket connection
5
-
server.retryDuration
Milliseconds to wait between retry attempts
60
-
authenticated
Whether target runner requires authentication or not
true
false
If server.balanced parameter is set to true:
server.host
Host identifier for connection
rsocket-runner-store-prod
-
server.refreshWindow
Seconds before refreshing load balance target list
10
-
If server.protocol parameter is set to tcp:
server.host
Hostname for connection
localhost
-
server.port
Port for connection
7001
7000
If server.protocol parameter is set to websocket:
server.baseUrl
Connection uri
ws://localhost:10101
-
Exposure of RSocket event runner APIs follows the same logic as RPC API flows.
Except for the CRUD based gateway systems, JSON body received by the API gateway is forwared to runners in event payload as a "parameters" data element. For CRUD based gateway systems, the body is forwarded as is, since the runners expect aggregate type data payload.
