Slack + Discord + Telegram dintr-un singur endpoint Fastify.

Brief

Un mic serviciu care preia un payload de notificare și îl distribuie către Slack, Discord și Telegram dintr-un singur endpoint. Folosit de restul platformei: ContentForge îl apelează pentru prompt-ul zilnic de revizuire, FB-Media îl apelează pentru alerte de pipeline, dashboard-ul homelab îl apelează pentru depășiri de prag.

Brief-ul a fost simplu: înlocuiește trei clienți de notificare diferiți (unul per canal) cu un singur endpoint HTTP care face ce trebuie. Reduce numărul de credențiale pe care fiecare proiect trebuie să le cunoască de la trei la una.

Arhitectură

Un singur endpoint Fastify (POST /notify) pe Node, rulând în CT 209 pe nodul Proxmox de servicii. Payload-ul este un plic subțire:

{
  "message": { "title": "...", "body": "...", "source": "..." },
  "severity": "info | success | warning | error | critical"
}

Handler-ul alege formatarea per canal (atașament Slack cu culoare, embed Discord cu icoană de severitate, Telegram Markdown cu emoji) dintr-un singur tabel de lookup, adăugarea unui al patrulea canal mai târziu înseamnă o singură intrare, nu o instrucțiune switch per canal.

Un al doilea endpoint (POST /telegram/webhook) ascultă mesaje Telegram primite și răspunde printr-un mic backend de chat bi-direcțional îndreptat către containerul Ollama de pe stația de lucru. Chat-ul este ținut în afara accesului public prin allowlist-ul botului Telegram (doar ID-urile de chat împerecheate primesc răspunsuri).

Rezultate

• 3 canale (Slack, Discord, Telegram) accesibile printr-un singur endpoint HTTP.
• O singură schemă de payload unificată, fiecare proiect care apelează folosește același plic.
• Chat Telegram bi-direcțional cu un backend Ollama pe stația de lucru, fără cost API per mesaj.
• Zero întreruperi neplanificate de la lansare, serviciul rulează ca o singură unitate systemd cu auto-restart.

Ce urmează

Două elemente pe lista pentru iterația următoare:

1. Standardizează maparea severitate → formatare-canal într-un mic tabel de lookup din prima zi, instrucțiunea switch per canal actuală este OK la trei canale, dar ar deveni neplăcută la șase. Refactor-ul cu tabel de lookup este în coadă.
2. Receptor de webhook pentru Prometheus AlertManager, platforma rulează deja Prometheus + Grafana; următorul consumator natural al /notify este AlertManager declanșând pe depășirile de prag Grafana.