pierluigi
commented
6 years ago After some conversations in https://fissionio.slack.com the "broker" pattern seems to be a good idea for our use case. In a nutshell, the architecture would look something like this:
GHApplet running on Fission
+------------------+ +-------------+-------------+
| | + + |
| JIRA Webhook +------> | |
| | | + |
+------------------+ | | |
| | |
| | | +------------+ +--------------------+
+------------------+ | /broker | broker() | | | | |
| | | HTTP trigger +--> Function +->Pub| NATS MQ | <----+ | Workflow B +
| GitHub Webhook +------> | | | | | Sub + e.g. Issue to ZenDesk
| | | | | +----+-------+ T: GH +
+------------------+ | | | ^ +--------------------+
| | | |Sub
+------------------+ | | | |Topic: JIRA
| | | | | |
| ... +------> | | | +-------+--------------+
| | | | | | |
+------------------+ | | | | Workflow A |
| | | | e.g. JIRA to PR |
+ + | | |
+ +----------------------+
We currently rely on a 1:1 mapping between HTTP endpoint and function name (e.g.
/gh/applets/issue-comment->fission fn --name issue-comment. This is inconvenient as for each endpoint we need to register a new GitHub App.A better solution would be to create a dispatcher function that based on the webhook will pass the request down to the appropriate function.