Implement hooks

[zorbash]

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.

[davejlong]

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.

[zorbash]

By totally configure-less you mean on the backend right?
How does this differ to POST/widgets/:id ?

[davejlong]

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
#4 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/AAKs1WYTbx8y0QBVitzhLwlhL645Uf9uks5q-3RkgaJpZM4Ksqc_
.

[zorbash]

Oh i see, one can though even now create a dashboard only using POST /widgets/:id and not a single elixir job.