Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Webhooks

 Webhooks

How to create a simple yet powerful webhooks mechanism in your PHP Application.

Guillaume Potier

May 24, 2016
Tweet

Other Decks in Technology

Transcript

  1. “A webhook in web development is a method of augmenting

    or altering the behavior of a web page, or web application, with custom callbacks. These callbacks may be maintained, modified, and managed by third-party users and developers who may not necessarily be affiliated with the originating website or application.” Wikipedia
  2. 1. consumer sets up a server to listen/consume callbacks 2.

    consumer registers callback URL with provider 3. provider makes requests to URL when a registered event happens
  3. ‣ a verb: POST ‣ an event: which could be

    subscribed by any user • for Github: pull_request, fork, commit, issues, etc.. ‣ a payload: containing the relevant data for the related event • often including: the resource itself, the sender (user who triggered the webhook) ‣ (optional) a security hash: to ensure webhook was delivered by the rightful authority • for Github: sharing a common secret used to generate a hash from the payload ‣ (optional) an ID webhook specs
  4. ‣ a CRUD API • a payload URL: the server

    endpoint that will receive the webhook payload • events list: which events would you like to subscribe to • (optional) the content type ‣ (optional) an history of recent deliveries ‣ (mandatory) a good documentation :) • try to mirror API resources • document possible events • document security mechanisms its registration
  5. 1. when a meeting is ended 2. when a task

    is created 3. when a task is assigned Solid implements these webhooks events
  6. ‣ Various entities in your codebase could trigger webhooks ‣

    Action that triggers webhooks could be in your services, your controllers, your commands. Pretty much everywhere ‣ You do not want to couple too much webhook logic from the rest of your application events to the rescue => use an event dispatcher symfony/event-dispatcher if you’re not using Symfony
  7. events to the rescue ‣ We dispatch a single event

    listened by a WebhookSubscriber. In the DeliveryEvent we pass: • the event / action name • the related entity • the user that made the action triggering the webhook • (optional) changeset or other extra contextual params
  8. ‣ lookup for registered users for each webhook could be

    consuming ‣ sending many POST requests for potential registered users *is* slow and consuming ‣ the API call that creates, updates or delete a resources and triggers the webhook does not need at all to be aware of all that stuff and worse, waiting for hooked URLs answers! RabbitMQ for the scalability => no need to do that stuff synchronously, use AMQP btw swarrot/swarrot is a great lib for RabbitMQ
  9. The command ‣ pros • well decoupled from the rest

    of the codebase ‣ cons • some extra queries (need to re-fetch entities we had in previous context) • works only for stored entities retrievable with unique ID