What’s that ?
Gluer is the entry point of every request and propose multiple working modes depending on the request :
- Proxy mode : for static resources that does not requires rewriting (fonts, images, …)
- Proxy mode with rewrite : for textual resources (css, js, html), this rewriting is necessary for resources “sharding” in a CDN or to prefix URL for routing purpose.
- The Fragment processing mode : in this scenario, Gluer contacts a Backend application to get the backbone of a page then detect, call and add components present in this backbone.
- The Application processing mode : in which it contacts a “Micro front-end” application to constitue the body of a page and render it inside a page backbone (Page model resolved by Shaper web)
The most common mode is the ‘Fragment processing’ mode, in which the request match a resource (check Resolver) represented by a Page or Page Model including multiple fragments. Gluer will act like the “glue” that will glue your components together to render a content.
See Processing for detailled workflows
Features
Configuration
Sites & applications
Sites configuration and applications (including backends) are fetched from the Registry at startup.
Gluer subscribe on the Registry event stream to keep configuration up to date.
1
2
|
kobi.registration:
base-url: # URL of the registy api
|
Couchbase bucket
Gluer use a Couchbase bucket to store and retrieve URL resolution, you must configure this bucket (values configured below are the default values if you do not set properties).
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
|
resolver.couchbase:
cluster:
hosts: # comma separated list of couchbase host
bucket: # Name of the couchbase bucket used for resolver
username: # Username for the bucket
password: # Password for the bucket
environment:
max-request-lifetime: 75000 # Sets the maximum time (in milliseconds) a request is allowed to live
connect-timeout: 5000 # Connect timeout
query-timeout: 5000 # Query timeout
view-timeout: 5000 # View timeout
search-timeout: 5000 # Search timeout
query:
scan-consistency: REQUEST_PLUS # Please do not modify. Consistency between index and data (NOT_BOUNDED, REQUEST_PLUS, STATEMENT_PLUS, see https://docs.couchbase.com/server/current/indexes/performance-consistency.html
caches:
objects:
max-memory-size: 10485760 # Max memory size (in bytes) for document by key cache (exclusive with max-entry-size)
max-entry-size: # Max entry size for document by key cache (exclusive with max-memory-size)
ttl: 86400 # Time To Live (in seconds) for document by key cache
views:
max-memory-size: 1048576 # Max memory size (in bytes) for key by view cache (exclusive with max-entry-size)
max-entry-size: # Max entry size for key by view cache (exclusive with max-memorysize)
ttl: 86400 # Time To Live (in seconds) for key by veiw cache
searches:
max-memory-size: 1048576 # Max memory size (in bytes) for key by search cache (exclusive with max-entry-size)
max-entry-size: # Max entry size for key by search cache (exclusive with max-memory-size)
ttl: 86400 # Time To Live (in seconds) for key by search cache
resolver:
cache:
unpersistable-paths: # Paths resolution not persisted in database (status 301, 302, 404, 410, 500)
max-memory-size: 10485760 # 10 MBytes
ttl : 86400 # Time to live in seconds, remote resolver may set a ttl lower than this one
ttl-on-error: 60 # Time to live in seconds if error occur while resolving path, should be lower than ttl
unpersistable-resources: # Resource resolution not persisted in database (status 500)
max-memory-size: 10485760 # 10 MBytes
ttl : 86400 # Time to live in seconds, remote resolver may set a ttl lower than this one
ttl-on-error: 60 # Time to live in seconds if error occur while resolving resource, should be lower than ttl
client:
connect-timeout: 200 # Client connect timeout to a remote resolver
read-timeout: 300 # Client read timeout to a remote resolver
max-connection: 100 # Client max connections to a remote resolver
|
VertX Server
VertX Server is used to handle incomming request (values configured below are the default values if you do not set properties)
1
2
3
4
5
6
7
8
9
10
11
12
|
vertx.httpserver.port: 8080
vertx.httpserver.idle-timeout: 60
vertx.httpserver.use-pooled-buffers: true
vertx.httpserver.tcp-keep-alive: true
vertx.httpserver.tcp-no-delay: true
vertx.httpserver.accept-backlog: 1000
vertx.httpserver.receive-buffer-size: -1
vertx.httpserver.send-buffer-size: -1
vertx.httpserver.max-header-size: 8192
vertx.httpserver.max-chunk-size: 8192
vertx.httpserver.compression-supported: true
vertx.httpserver.compression-level: 6
|
VertX Client
VertX Client is used to proxy incomming request to backend or application (values configured below are the default values if you do not set properties)
1
2
3
4
5
6
7
8
9
10
11
|
vertx.httpclient.max-pool-size: 1000
vertx.httpclient.max-wait-queue-size: 1000
vertx.httpclient.idle-timeout: 60
vertx.httpclient.connect-timeout: 1000
vertx.httpclient.tcp-keep-alive: true
vertx.httpclient.keep-alive: true
vertx.httpclient.tcp-no-delay: true
vertx.httpclient.use-pooled-buffers: true
vertx.httpclient.receive-buffer-size: -1
vertx.httpclient.send-buffer-size: -1
vertx.httpclient.max-chunk-size: 8192
|
Async HTTP Client
Async HTTP Client is used to resolve fragment (values configured below are the default values if you do not set properties)
1
2
3
4
5
6
7
8
9
10
|
async.httpclient.socket-timeout: 60000
async.httpclient.connect-timeout: 1000
async.httpclient.connection-request-timeout: 1000
async.httpclient.so-keep-alive: true
async.httpclient.tcp-no-delay: true
async.httpclient.max-total: 10000
async.httpclient.max-per-route: 1000
async.httpclient.send-buffer-size: 0
async.httpclient.receive-buffer-size: 0
async.httpclient.buffer-size: 8192
|
Cookies
Generate cookie
You can use Gluer to generate cookies on incoming or on outgoing request, a common usage of this feature is to route request with AB distribution during your transition from your legacy front to KOBI.
Generate cookie on incoming request
If you want to generate cookies on incoming request (cookie will be sent on outgoing request but will be available immediately as if user sent the cookie itself), you have to use kobi.request.cookies.generator property with the syntax explained below.
Generate cookie on outgoing request
If you want to generate cookies on outgoing request, you have to use kobi.response.cookies.generator property with the syntax explained below.
Syntax
Below the syntax to configure incoming and outgoing cookie generation.
- If at least one value is set in configuration :
- If user comes without this cookie : cookie will be generated with one of the possible value depending ponderation.
- If user comes with this cookie and one of the possible value : nothing happen (cookie stay alive).
- If user comes with this cookie and a value not existing in the list of possible value : cookie will be generated with one of the possible value depending ponderation.
- If no value is set in configuration (
values attribute is missing from configuration) :
- If user comes without this cookie : nothing happen.
- If user comes with this cookie and any value : cookie will be generated with an empty value and with a max-age=0, the cookie will be removed immediatly from the client
1
2
3
4
5
6
7
8
9
10
11
12
13
14
|
kobi.(request|response).cookies.generator:
my_cookie_name: # Name of the cookie
path-pattern: # Path pattern used to filter cookie generation (If not set then all paths match).
disable-with-designer: false # If true then cookie will not be generated if request comes from KOBI Designer (default false)
secure: false # Should the cookie be created as secure (if true then cookie will be available only with HTTPS, default false)
http-only: false # Should the cookie be created as http-only (f true then cookie willnot be available from javascript, default false)
path: / # The path on which the cookie will be available (default /)
domain: # Domain on which the cookie will be available (cookie will be generated only if domain math with the request doamin name, default not set)
max-age: 300 # The max duration of the cookie (in seconds)
values: # A list of cookie values with a weighting.
value1: weighting1 # value is one of the possible value for the cookie and weighting1 is a positive integer (If you want to have a weighting of 50%, just type 50 and be sure the sum of all weighting is 100)
value2: weighting2
value3: weighting3
...
|
Rename cookie
You can use Gluer to rename incoming or outgoing cookies
Rename incoming cookie
This is the syntax to rename incoming cookie
1
2
3
4
|
kobi.request.cookies.rename:
incomming_cookie_name1: renamed_cookie_name1
incomming_cookie_name2: renamed_cookie_name2
...
|
Rename outgoing cookie
This is the syntax to rename outgoing cookie
1
2
3
4
|
kobi.response.cookies.rename:
outgoing_cookie_name1: renamed_cookie_name1
outgoing_cookie_name2: renamed_cookie_name2
...
|
You can use Gluer to rename incoming or outgoing header
This is the syntax to rename incoming header
1
2
3
4
|
kobi.request.headers.rename:
incomming_header_name1: renamed_header_name1
incomming_header_name2: renamed_header_name2
...
|
This is the syntax to rename outgoing header
1
2
3
4
|
kobi.response.headers.rename:
outgoing_header_name1: renamed_header_name1
outgoing_header_name2: renamed_header_name2
...
|
Backends error
This configuration is used to route the error status to a specific destination
1
2
3
4
5
6
7
8
9
|
kobi.routing.errors:
status-pattern: # http response status code
host-pattern: # host pattern used for backend routing.
path-pattern: # path pattern used for static resources.
src: # url destination
use-host-header: #
refresh-delay: # frequency for refreshing
retry-delay: # delay between retry attempts.
retry-count: # when greater than zero, enables retrying of failed sends.
|
