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 the 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.
• 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
• 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-millis: Timeout for requesting the src URL. Defaults to global requestTimeout
  • fallback-src: URL of the fragment to include in case the request to src failed
  • fallback-src-timeout-millis: Timeout for requesting the fallback-src URL. Defaults to global requestTimeout
  • primary: Denotes a fragment whose response code is set as response code for the page
• Precedence for resolving: src → fallback-src → fallback content

Full Example:

<ableron-include
        id="header"
        src="https://example.com/api/fragments/header"
        fallback-src="https://cdn.example.com/static/fallback-header">
        <header>Static fallback header</header></ableron-include>

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