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

Common 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

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.

For Styx control plane and server objects (providers and servers namespaces) only:

• GET /admin/providers - Renders an HTML list of all configured provider objects.

• GET /admin/providers/<:NAME>/status - A provider object status.

• GET /admin/servers - Renders an HTML list of all configured server objects.

• GET /admin/servers/<:NAME>/port - Returns the configured port number, if the server is running.

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 object) attributes. The full object configuration must be uploaded.

• Can not query individual object attributes. The REST API always returns a full object configuration.

Control Plane and Server Objects

Control plane and the server objects are designed to be extensible. They can offer a custom interface which Styx makes available under:

• GET /admin/providers/<:NAME/<:EXTENSION-SUBPATH> - Invokes a custom endpoint on the provider object.

This endpoints vary between the provider object types.