Des Webhooks pour republier des contenus sur d'autres plateformes

[thom4parisot]

Où republier :

• créer un post via l'API Mastodon
• lancer un build sur un dépôt GitHub ou GitLab (type lampadaire.ca ou sens-public.org)
• créer un post sur un canal Mastodon

Design d'API

Création d'un webhook

Via API pour l'instant.

mutation webhookSetup ($user: ID!, $hook: WebhookInput!) {
  user {
    webhooks {
      url
      # ['article:created', 'version:created', 'article:deleted'] etc.
      events
      logs (limit: 5) {
        # ['article:{id}', 'version:{id}']
        input
        # 
        output
        date
        # WEBHOOK_SUCCESS | WEBHOOK_FAILURE
        status
      }
    }
  }
}

input WebhookInput {
  url: URL
  events: [WebhookEvent]
}

enum WebhookEvent {
  article:created
  article:deleted
  version:created
  version:deleted
}

Scheduling de l'événement

Avec agenda par exemple :

agenda.now('userContentUpdated', { user: '{id}', article: '{articleId}', version: '{versionId}' }

Le worker effectue un truc comme :

const [user, webhooks] = User.findWebhooksWithPayload(payload)

for await (const { date, inputs, output, status } of executeWebhooks(webhooks)) {
  user.webhooks.logs.push({ date, inputs, output, status })
}

await user.save()

[ggrossetie]

C'est donc un webbook 🚪🏃‍♂️

[thom4parisot]

⬆️ ça te parle si on part avec ce fonctionnement @Mogztter ?

[ggrossetie]

@thom4parisot oui ça me semble pas mal.

input WebhookInput {
  url: URL
  events: WebhookEvent
}

Je suppose que c'est une liste de WebhookEvent non ?

• article:deleted: on publie un event par rapport au owner de l'article, à l'utilisateur qui a fait l'action ou à l'ensemble des utilisateurs qui avaient accès à cet article ?

Si on veut être cohérent par rapport à article:created, je pense qu'il faut publier un event par rapport à l'utilisateur qui fait l'action non ?

Je réfléchissais aux webhooks dans un contexte d'espace de travail mais je pense que les webhooks doivent rester associé à un utilisateur (les webhooks sont personnels).

Par contre je pense que ça peut être bien d'ajouter un contexte avec l'event. Par exemple, article:added dans l'espace de travail id : 123 ou tag:added avec le tag id : 456. On pourrait aussi parler de scope qui limite le périmètre, soit on écoute l'ensemble des ajouts de tags soit on peut réduire le scope.

Cela dit on peut déjà commencer simple et voir l'usage qui en est fait.

[thom4parisot]

Bonnes remarques, et bonnes questions !

Je le vois applicable aux workspaces aussi.

L'envie est de commencer et de se limiter aux owner, via API uniquement, mettre en prod, voir ce que ça donne, et itérer ensuite.

À terme, une personne collaboratrice qui publie une version d'un article partagé devrait déclencher les webhooks qui remplissent les conditions du owner et collaborators. Et pouvoir gérer ça via l'interface web de Stylo.