Admin Interface Design

Admin Interface Design

This page tracks any new ideas and improvements to Styx admin interface.

Background

The admin interface, as documented in Admin Interface documentation, is built for the old Styx application router. The old application router:

• Determines a backend application based on URL path prefix.
• Load balances between origins configured for that application.
• Reads this configuration from origins yaml configuration file. The routing logic remains static after that.

For this reason the admin interface is really simple. It has a dashboard for monitoring live origin status, and endpoints for viewing the configuration, and few simple POST commands to reload the origin file and/or enable/disable individual origins.

The new Styx object model splits the old application routing into separate composable routing objects. These changes are reflected in the admin interface accordingly.

Styx Configuration Objects

The new Styx Object Model:

• Describes Styx data path, ie. the filtering and routing, in terms of composable routing objects.
• Configures Styx control plane also in terms of service provider objects.
• Declares Styx servers and executors as appropriate configuration objects.

These objects share the same configuration format, and we call them Styx configuration objects. They just serve different purposes and therefore live in separate namespaces. In styx configuration file:

#
# Styx data plane:
#
routingObjects:
  myHttpPipeline:
    type: InterceptorPipeline
    config:
      .. object config ...

  myApplicationRouter:
    type: PathPrefixRouter
    config:
      .. object config ...

#
# Styx Control Plane:
#
providers:
  myHealthCheckProvider:
    type: HealthCheckMonitor
    config:
      .. provider config ...

#
# Styx HTTP servers
#
servers:
  myOwnHttpServerName:
    type: HttpServer
    config:
      port: 8443
      handler: myHttpPipeline
      tlsSettings:
        ...
        ...

RESTful Admin Interface

The new object model lends itself very well to a RESTful API. We have implemented a following structure so far:

The object namespaces are per configuration object type:

• Data path: /admin/routing/...
• Control plane: /admin/providers/...
• Servers: /admin/servers/...