Implement hooks
Currently one can update a widget either using a job or HTTP POST to /widgets/:id.
We could also allow settings hooks for easier integration with external services.
Example usage with GitHub webhooks:
# File: hooks/github.exs
hook :github_issues do
issue = body |> Poison.decode!
# Other, heavier processing can be added here
broadcast! :github_issues,
%{user: issue |> get_in(["sender", "login"]),
title: issue |> get_in(["issue", "title"])}
end
Kitto with the above hook definition would pass the request context and handling of POST /hooks/github_issues to the code in the hook.
Had this thought from #21. When building out hooks there should be a general hook where any service can POST to /hooks/some_hook which will broadcast whatever the POST body as some_hook. Totally configureless so someone can build out a real time dashboard based on webhooks without writing a single line of Elixir.
By totally configure-less you mean on the backend right? How does this differ to POST/widgets/:id ?
In building this out I would probably look to bring POST /widgets/:id
into the hooks. Implementation. The current implementation requires the
hook to post a specific format. The hook implementation would flip it to
enforce the widget to take in the data specific to the metric.
On Wed, Nov 16, 2016, 4:23 PM Dimitrios Zorbas [email protected] wrote:
By totally configure-less you mean on the backend right? How does this differ to POST/widgets/:id ?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kittoframework/kitto/issues/4#issuecomment-261076467, or mute the thread https://github.com/notifications/unsubscribe-auth/AAKs1WYTbx8y0QBVitzhLwlhL645Uf9uks5q-3RkgaJpZM4Ksqc_ .
Oh i see, one can though even now create a dashboard only using POST /widgets/:id and not a single elixir job.