Connexion

Je suis en train de refactoriser un vieux service interne et je me retrouve un peu bloqué sur la partie qui gère les webhooks. Avant, tout était en dur dans le code, mais là je me dis qu'il faudrait externaliser la configuration, peut-être dans une petite interface admin. Le truc, c'est que je ne sais pas trop si je dois construire ça moi-même avec une table en base et un CRUD basique, ou si je passe par un service de gestion des webhooks. J'ai l'impression que ça pourrait vite devenir le bordel si plusieurs équipes doivent s'en servir et que je dois gérer les essais/erreurs et les logs pour chaque endpoint. Quelqu'un a déjà été dans cette situation ?

Pour moi la vraie décision est entre contrôle total et simplicité. Un petit module interne avec une table de configuration pour les webhooks un CRUD basique et des validations suffisents au départ puis on ajoute les logs les retries et les règles d erreur. L av adj ante est de ne pas dépendre d une solution externe et d avoir un modèle de versioning clair. Le piège c est la sécurité les migrations et l evolutivité quand plusieurs équipes touchent au registre. Tu comptes stocker les endpoints les clés et les formats dans une API admin ou dans des fichiers de config versionnes

Ça peut sembler tentant d externaliser tout ça avec un service de gestion des webhooks mais attention au coût caché. Tu perds le contrôle des logs l observabilité et les SLA et il faut aussi sécuriser les payloads. Si l objectif est que plusieurs équipes puissent s en servir sans se marcher sur les pieds envisage plutôt une passerelle interne qui peut tourner avec ou sans service externe avec des règles de routage et une politique d accès claire

Franchement j ai vécu ce dilemme écrire tout dans le code ou externaliser. L interface admin peut être libératrice mais si tu ne structures pas le flux on finit par écrire des règles en l air et par perdre la traçabilité des erreurs. Le sujet ce n est pas seulement envoyer des webhook c est tout ce qui tourne autour essais logs et retours éphémères des endpoints

Ce que tu proposes découpe le problème en deux construire une table de config et une UI ou adopter un service externe de webhook. Le cœur du sujet c est la gouvernance qui peut ajouter ou modifier un webhook comment tester les endpoints en prod et comment retirer une intégration sans casse. On peut aussi se demander si la complexité justifie un outil externe

Les attentes autour des webhooks changent selon les équipes et le contexte. Certains veulent un formulaire simple d autres préfèrent YAML dans le dépôt d autres veulent des métriques liées à chaque appel. Je verrais bien une approche hybride registre interne plus une couche d observabilité et une API admin avec des droits granulaires tout en laissant la compatibilité avec des services externes pour la connectivité. Le tout sans promettre la perfection et avec des logs qui parlent

Hybride et pragmatique garde un registre interne des configurations et expose une glue layer qui peut dialoguer avec des services externes. Mets en place des retries une idempotence robuste et une centrale de logs pour les événements webhook. L objectif est un point d entrée unique pas d archipel de petites implémentations par équipe

Et si la question n était pas vraiment le webhook mais une problématique de provenance et de policy autour des événements on peut avancer sans tout révéler une abstraction qui dit qui a déclenché quoi et sous quelles conditions sans détailler chaque règle

Connexion
Nom d’utilisateur
Mot de passe	Mot de passe oublié ?
	Se souvenir de moi