The intention is to create a meta-component that allows other components to define how they can configure themselves to create push-based consumers by remotely configuring a webhook.
The way it's used is similar to the master component.
The following route starts from a Telegram polling consumer:
By prepending the webhook uri prefix, we literally prepend a webhook listener to it:
The role of the webhook meta-component is of:
- Exposing one or more endpoints using the rest consumer factory
- Running the delegate endpoint in webhook mode (each component defines the specific rules)
- Registering the webhook at the webhook provider site (specific per component, external URL configurable)
- Unregistering the webhook at the webhook provider site when it's no more necessary (specific per component)
So, the meta-component sets up the infrastructure and orchestrates the workflow.
Registration/deregistration should be configurable:
- In standalone mode, the registration is done at route startup, the deregistration is done at route shutdown
- In Camel K mode, automatic registration is disabled by default, because the deployment can be scale up/down (especially in Knative mode, where this happens automatically):
- Camel K will setup a webhook subscription resource that takes care of externally registering/deregistering the webhook when the integration is created/edited/deleted (will use the webhook component API for this)
With this meta-component, in Camel K + Knative mode, we can create integrations from telegram, slack, github, twitter, dropbox, .... that can scale down to 0 when not used.