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.

Avatar for Guillaume Potier

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