Proposal: Add support for admission webhook

[felipeweb]

Context

This is a proposal to add support for admission webhook in the same way that have in Kubernetes.

Use cases

• As a developer I want to add a dynamic default values to my HTTP request and thus deliver a better customer experience.
• As a developer I want to add a dynamic validation to my HTTP request and thus deliver a better customer experience.

Implementation idea

• Admission webhook servers must expose a HTTP POST endpoint;
• Prestd execute the post requests after all core middlewares;
• Prestd must convert XML requests and always send json to webhooks;
• A route can have multiple webhooks attached;
• If the route have multiple webhooks attached, it will be executed in the order that is declared in configuration;
• A mutation and validation webhook must be able to send and receive content like representations bellow;
• Body changes performed by a mutation webhook must be propagated to rest of the request

Representations

Errors

Any status code != 200 will be treated as error and response should follow representation bellow:

{
    "error": "error message"
}

Input for mutation and validation webhook

{
    "database":"db name",
    "schema":"schema name",
    "table":"table name",
    "body":{
        "field1":"value1"
    }
}

Output for mutation

{
    "field1":"value1"
}

Output for validation

If status code is 200 body will be ignored

Configuration file example

[[admissionWebhooks]]
kind = "mutation"
database = "database name"
schema = "schema name"
table = "table name"
address = "http://localhost:9090/mutate"
verbs = [ "POST", "PATCH" ]

[[admissionWebhooks]]
kind = "validation"
database = "database name"
schema = "schema name"
table = "table name"
address = "http://localhost:9090/validation"
verbs = [ "POST", "PATCH" ]

[avelino]

I don't know if this feature would be used in most projects (apis), although it is excellent.

Could it be time to implement support for writing middleware via a plugin?

And have a plugin with this feature

This way we don't "inflate" the core of prestd with too many resources and we support plugins for those who need the resource

[felipeweb]

We need a more robust plugin system that support inputs to use as a middleware, because input can change during middleware chain. We can redesign the plugin system to use HTTP or GRPC with hashicorp's go-plugin package.

[avelino]

I like the idea of evolving the existing plugin system

The important thing is to leave the extensive prestd as OpenCode and not to inflate (get heavy) the core

[avelino]

Reading about the hashicorp's go-plugin package it works differently from the way the prestd plugin works, now it is more extensive and easy to distribute via a .so file, being possible to create a marketplace system - opening up an opportunity to market the plugin

With the hashicorp's go-plugin package it will not be so "simple“

[arxdsilva]

Use cases

• As a developer I want to add a dynamic default values to my HTTP request and thus deliver a better customer experience.

• As a developer I want to add a dynamic validation to my HTTP request and thus deliver a better customer experience.

Can you further exemplify why you need such features or propose that we implement them?

I understand that k8s does that as it can be part of app management, but why would that behavior be important to prestd?

[felipeweb]

Let me put an exemple here: I have a table Category and the properties table and category default values changes based on properties. I do not want to create a New route to perform this kind of manipulation.

[avelino]

We are making prestd more stencil by using the existing plugin architecture for endpoint (http), where it is possible to make prestd plugin by writing operating system library

We implemented the first middleware version in this pull request #798

thanks @felipeweb for the provocation (opening this discussion) and especially for the contribution sending the implementation code