zalando/skipper

Using Skipper for implementing webhooks

cloudcompute opened this issue · 6 comments

Can we use Skipper to connect our application with other applications using Webhook protocol?

My 'triggering' application serializes data and send it to a webhook URL to another 'processing' application let's say CRM. The CRM application can then send a message (with an HTTP status code like 302) to let the triggering application know if the data was received successfully or 404 if not followed by the response.

Skipper must be queuing the HTTP requests (including the webhook requests) somewhere.. in a store like Redis or etcd or some other?

Could you please elaborate this in little detail?

Thanks

Can you draw a picture to clarify communication paths and steps?
In general it sounds like you could construct some routes to do what you want, but maybe you need to build a special filter for that. Skipper is a first class library to build proxies so it seems that you can also do very complex things that are not yet part of the binary offering.

Hi @szuecs

I somehow missed your messages, sorry for that.

My application (sends a request to Skipper to create a webhook for a CRM application) -------> Skipper (receives this request and the Webhook functionality built into Skipper further creates the webhook on my application behalf and sends it to the target CRM application) ---------> CRM application (processes the request and sends the result back to Skipper)

So I want to use Skipper's Webhook functionality (without writing my own) as an intermediate between my application and the other apps. I don't know whether Skipper exposes API for the same.

I am not sure if you and I have the same meaning for the term "webhook".
A picture would make it simpler for us to understand each other.

For me your description could achieved by pure routing instead of a webhook. For example

api: PathSubtree("/api") -> "http://my-api.example";
webhook: PathSubtree("/cms") -> "http://my-crm.example";

Interesting would be what the webhook would do and what should skipper do with the response from the webhook.

There's an example webhook() filter that allows the webhook target to enforce authnz for the http request:

api: PathSubtree("/api") -> webhook("http://my-auth.example/auth") -> "http://my-api.example";

Thanks @szuecs for the answer. I was looking for the full-fledged webhook solution. I think Skipper does not serve that purpose.

I have few questions

a. How can i integrate Skipper with Zitadel for authentication purposes?

b. Does Skipper has the API gateway functionality .. splitting a request to multiple backends / microservices and then aggregating the API responses, Or can I add a a Graphql aggregation/gateway plugin?

c. Traefik is very popular than Skipper. I don't think Traefik offers those many features like Skipper does, is it simply because of hype?

Regards

Thanks @szuecs for the answer. I was looking for the full-fledged webhook solution. I think Skipper does not serve that purpose.

I don't know what you mean by "full-fledged webhook solution".

I have few questions

a. How can i integrate Skipper with Zitadel for authentication purposes?

I don't know how Zitadel works. You have to understand what protocols they offer to integrate with applications.
We can do OAuth2 auth code grant flow and OpenID Connect, both are standards.

b. Does Skipper has the API gateway functionality .. splitting a request to multiple backends / microservices and then aggregating the API responses, Or can I add a a Graphql aggregation/gateway plugin?

No we are not an API gateway.
If you really want you can create lua filter that calls multiple endpoints and aggregate the results, but I think that would be a poor solution.

c. Traefik is very popular than Skipper. I don't think Traefik offers those many features like Skipper does, is it simply because of hype?

From my side we are of course better suited to all http related services than everyone else including Traefik.
From availability point of view you can DoS Traefik and skipper has protection for it.
From usability point of view I think skipper beats any other proxy, because of our route definitions are simple and you can compose features.