6. “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
9. 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
19. ‣ 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
20. ‣ 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
21.
22.
23. Let’s implement it in your PHP application!*
*We’ll see at least how we did it for Solid
29. 1. when a meeting is ended
2. when a task is created
3. when a task is assigned
Solid implements these webhooks events
30. ‣ 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
31. 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
32. ‣ 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
35. 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