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/...

In each namespace (routing/providers/servers):

• GET /admin/<NAMESPACE>/objects returns a list of configured objects in that namespace.
• GET /admin/<NAMESPACE>/objects/<:NAME> returns a configuration for that object only

In addition, for Styx data plane objects (routing namespace) only:

• PUT /admin/routing/objects/<:NAME> Replaces this object with new configuration.
• DELETE /admin/routing/objects/<:NAME> Removes this object.

Limitations:

• Only data plane routing objects can be modified or deleted. This was implemented for black box testing purposes. I think we should toggle this feature off for production systems.

• Can not modify individual routing attributes. The full object configuration must be uploaded.