Ableron UI Composition

Server Side - Happens in your services before sending the response to the client.

Dynamic - Composition is performed during runtime of the services instead of compile time. This makes quality assurance a bit harder, but brings significant value regarding decoupling of your teams and services.

Distributed - No centralized infrastructure component which is performing the UI composition. Instead, each service is performing UI composition itself using an Ableron library.

Ableron intercepts the HTTP response sent by your service and resolves all <ableron-include>-HTML-tags with their respective remote fragment. This is achieved via installing Ableron as a dependency in your service, which is doing the magic

Compared to Server Side Includes via nginx and thus an architecture where a dedicated infrastructure component is performing UI composition:

• Lean Infrastructure: No need to route all your traffic through an infrastructure component which is performing the UI composition
• Easy Local Development: Includes are resolved directly in your service. This works fine for local development and increases developer experience.
• Easy Configuration: Your can easily define different timeouts, fallback fragments or static fallback content for each of your includes.
• Local Caching: All fragments are cached in memory directly within your service according to the cache policy of the fragments. This saves HTTP calls and thus money as well as latency.

In order to use Ableron in your service, there needs to be an Ableron library which is compatible with the technology used in your service.

Available framework integrations:

• Spring Boot 2
• Spring Boot 3
• express
• fastify

Available basic implementations:

• Java
• JavaScript

• Must be closed, i.e. either <ableron-include ... /> or <ableron-include ...></ableron-include>
• Content between <ableron-include> and </ableron-include> is used as fallback content
• Attributes
  • id: Unique name of the include used within log messages
  • src: URL of the fragment to include
  • src-timeout: Timeout for requesting the src URL. Defaults to global requestTimeout set via config. Value can either be a plain number (e.g. 2000 - treated as milliseconds), a number suffixed with ms (e.g. 2000ms - treated as milliseconds) or a number suffixed with s (e.g. 2s - treated as seconds)
  • fallback-src: URL of the fragment to include in case the request to src failed
  • fallback-src-timeout: Timeout for requesting the fallback-src URL. Defaults to global requestTimeout set via config. Value can either be a plain number (e.g. 2000 - treated as milliseconds), a number suffixed with ms (e.g. 2000ms - treated as milliseconds) or a number suffixed with s (e.g. 2s - treated as seconds)
  • primary: Denotes a fragment whose response code is set as response code for the page
  • headers: Comma-separated list of request headers, that shall be forwarded from the parent request to fragment requests. These Headers become part of the cache key for the requested URL.
  • cookies: Comma-separated list of cookies, that shall be forwarded from the parent request to fragment requests. These Cookies become part of the cache key for the requested URL.
• Precedence for resolving: src → fallback-src → fallback content

Examples:

<ableron-include
        id="header"
        src="https://example.com/api/fragments/header"
        fallback-src="https://cdn.example.com/static/fallback-header"
        headers="x-ab-test-groups,x-country"
        cookies="device,consent">
        <header>Static fallback header</header></ableron-include>

<ableron-include id="header" src="https://example.com/api/fragments/header" src-timeout="2s" />

Treating an include as primary leads to not only include the fragment but also to let the fragment control the HTTP response status code as well as response headers. How primary includes work:

• If src returns success status, this status code is set as response code for the page
• If src returns error status, fallback-src is defined and returns success status, this status code is set as response code for the page
• If src and fallback-src return error status, the status code returned by src is set as response code for the page
• If src and fallback-src return error status, the fragment content equals the body returned by src. Fallback content is ignored

Fragments are considered cacheable if they have HTTP status code:

• 200, 203, 204, 206
• 300
• 404, 405, 410, 414
• 501

Cached fragments are being refreshed automatically, if enabled. By default, auto refreshing is disabled.
If auto refresh is enabled, cached fragments are getting asynchronously refreshed before they expire. This reduces the cache miss rate and thus has a positive impact on latency. On the other hand, additional traffic is introduced, because the cached fragments are loaded again even before their actual expiration time
Fragments are tried to be refreshed when only 15% of their initial time to live remains. In case of failure, refresh is repeated three times with a static delay of one second.

The maximum number of consecutive refreshs of inactive cached fragments can be configured. Fragments are considered inactive, if they have not been read from cache between writing to cache and a refresh attempt.