Ce matin, je cherchais un moyen simple de tester des webhooks en local sans passer par ce bon vieux Ngrok qui est devenu un peu relou avec ses limites en version gratuite. J'ai d'abord pensé à monter mon propre serveur VPN (coucou Tailscale), mais franchement flemme.
Et puis tout à fait par hasard (aaah les joies de la sérendipité) je suis tombé sur cet outil qui devrait vous plaire, surtout si vous développez des applis qui doivent recevoir des notifications HTTP (GitHub, Stripe, Slack...). Ben oui vous connaissez la galère... votre serveur de dev est sur "localhost", donc inaccessible depuis l'extérieur, du coup, impossible de recevoir ces fameux webhooks sans ouvrir votre routeur ou utiliser un tunnel.
C'est là qu'intervient Webhooks Proxy Tunnel !
Grâce à cet outil, au lieu de multiplier les intermédiaires, vous déployez votre propre tunnel... directement sur l'infrastructure de Cloudflare. Et le meilleur c'est que ça tourne généralement très bien sur leur offre gratuite (dans la limite des quotas Workers évidemment, donc attention si vous bourrinez comme un fifou).
L'outil utilise un Cloudflare Worker couplé à un Durable Object (une sorte de mini-serveur d'état). Le Worker reçoit alors les requêtes publiques sur une URL en HTTPS (genre "truc.workers.dev") et les transmet via une WebSocket à un petit client Node.js qui tourne sur votre machine. Et hop, le trafic arrive sur votre port local.
Perso, je trouve ça brillant car même si le trafic passe techniquement par Cloudflare (puisque c'est leur infra), vous gardez la main sur le code qui s'exécute et vous évitez d'envoyer vos données à un service tiers supplémentaire dont vous ignorez tout.
Pour l'installer, ne plus c'est hyper fastoche. Il vous faut juste un compte Cloudflare et Node.js. J'ai testé l'install en moins de 5 minutes, vous clonez le dépôt, vous installez les dépendances et vous lancez le déploiement (qui vous demandera de vous authentifier) :
Connexiongit clone https://github.com/peter-leonov/webhooks-proxy-tunnel.git
cd webhooks-proxy-tunnel/worker
npm install
npm run deploy
Une fois déployé, le script vous donne une URL et il ne vous reste plus alors qu'à lancer le client local en lui disant où taper (par exemple votre port 3000) et le tour est joué !! Vous pouvez même gérer plusieurs tunnels en parallèle si vous bossez sur plusieurs projets, chaque tunnel ayant son ID unique.
Attention quand même, c'est conçu pour du développement hein, pas pour streamer de la 4K. Les requêtes doivent tenir en mémoire (limite de 100 Mo environ) donc sauf si vous transférez des fichiers énormes via vos webhooks, ça passera crème pour du JSON ou des petits payloads binaires.
Voilà, si vous cherchiez une alternative self-hosted et gratuite pour vos tests, c'est clairement un outil à garder sous le coude. Et si vous avez besoin de trucs plus costauds pour du réseau d'entreprise, jetez un œil à Tailscale ou Octelium .
Une nouvelle lib TypeScript pour travailler avec les PDF en Node.js ou Bun. Elle permet notamment de gérer les formulaires, les signatures, etc.
Elle ambitionne également de générer des PDF à partir de HTML dans le futur.
Une nouvelle lib TypeScript pour travailler avec les PDF en Node.js ou Bun. Elle permet notamment de gérer les formulaires, les signatures, etc.
Elle ambitionne également de générer des PDF à partir de HTML dans le futur.
Une librairie de génération de PDF minimaliste (moins de 400 lignes de code) pour Node.
Elle ne gère pas toutes les possibilités offertes par les PDF mais elle est parfaite pour générer des factures par exemple.
Une librairie de génération de PDF minimaliste (moins de 400 lignes de code) pour Node.
Elle ne gère pas toutes les possibilités offertes par les PDF mais elle est parfaite pour générer des factures par exemple.
La lib de signals (ce qui sous-tend le système de réactivité des frameworks JavaScript modernes) utilisée par Vue 3.6 en mode Vapor (alternative au virtual DOM).
La lib de signals (ce qui sous-tend le système de réactivité des frameworks JavaScript modernes) utilisée par Vue 3.6 en mode Vapor (alternative au virtual DOM).
Perso je n'ai presque jamais eu besoin du JS, encore aujourd'hui je ne l'utilise que dans des cas bien précis où c'est réellement nécéssaire, cet article est vraiment chouette et bien conçu.
Un remplaçant potentiel de ts-node et tsx pour exécuter du TypeScript avec Node.js. Il vise à limiter les risques de différences de comportement entre l'environnement de dev et de production, ce dont souffrent parfois ses concurrents.
Un remplaçant potentiel de ts-node et tsx pour exécuter du TypeScript avec Node.js. Il vise à limiter les risques de différences de comportement entre l'environnement de dev et de production, ce dont souffrent parfois ses concurrents.
J'applique systématiquement la même logique avec Zod mais dans src/config.ts. Ça permet d'éviter de nombreux problèmes au runtime.
Pour éviter les appels à process.env, il est possible d'utiliser la règle ESLint n/no-process-env et d'ajouter une exception pour le seul fichier src/config.ts.
J'applique systématiquement la même logique avec Zod mais dans src/config.ts. Ça permet d'éviter de nombreux problèmes au runtime.
Pour éviter les appels à process.env, il est possible d'utiliser la règle ESLint n/no-process-env et d'ajouter une exception pour le seul fichier src/config.ts.
