Couper should be easy to use but sometimes there may be more complex requirements from the surrounding architecture or a contributor may add a specific feature without the requirement to know the whole Couper source code. A subset of the plugin interface could be enough.

Technically we will make use of the Go Plugin functionality which enables Couper to load .so files on the fly while providing the path(es) as cli argument. This won't be supported on Windows systems but there would always a build from source fallback for such cases. The plugin must be build with same symbols as the Couper version which loads the plugin. Means same go version and debug -vs- non-debug build.

Mountpoints

Couper must have some code entrypoints to call(back) the plugin implementation, lets call them mountpoint.

• load and schema definition: register the hcl schema to extend the existing Couper hcl configuration
• construct and register: with parsed config values of given schema
• define the plugin type: handle access_control or being part of an endpoint or handling other connection types for a backend then http
  • endpoint: the plugin component will still be part of our sequence feature, so it would be valid that a http request will trigger a sequence with a normal request block and the "plugin" block can access the resulting variable and produce also variables which could be used for a response therefore the result type must be a cty.Object

That being said we have to "open" some internal packages to make a plugin developers life easier.