PodcastFeedVapor

PodcastFeedMaker sait générer, parser, valider et auditer des flux RSS podcast. Super. Mais une fois que vous avez votre XML tout propre… il faut bien le servir quelque part.

Dans un projet client, j'avais besoin de feeds générés à la volée depuis une base de données — pas de fichiers statiques, pas de CDN, du vrai RSS construit au moment de la requête HTTP. J'ai commencé par écrire un handler Vapor naïf : construire le feed, sérialiser, retourner la réponse. Ça marchait, mais sans ETag, sans Cache-Control, sans CORS, sans rien de ce qu'un flux RSS de production exige vraiment.

Plutôt que de réinventer ces briques à chaque projet, j'ai tout extrait dans une lib à part. PodcastFeedVapor est née de ce besoin concret : transformer n'importe quelle app Vapor en serveur de podcasts, avec tout ce qui va bien côté HTTP, tout en gardant une séparation stricte entre ce qui est réutilisable (la lib open-source) et ce qui est métier (votre app).

C'est une couche middleware pour Vapor qui s'intercale entre votre logique métier et le client HTTP. En gros : vous construisez un PodcastFeed avec le DSL de PodcastFeedMaker, et PodcastFeedVapor se charge du reste — les headers, le caching, le CORS, le streaming, la pagination.

Le tout est découpé en quatre targets Swift Package Manager. Vous importez uniquement ce dont vous avez besoin, pas plus.

Voici tout ce qu'il faut pour qu'une app Vapor serve un flux RSS podcast avec caching HTTP, CORS, et un header de génération personnalisé. Pas de magie, juste de la config :

Un GET /feed.xml retourne du XML avec Content-Type: application/rss+xml, un ETag SHA256, un Cache-Control: public, max-age=3600, un Last-Modified, et un header X-Generator: MyApp/1.0. Le tout en 200 OK la première fois, puis 304 Not Modified ensuite si le contenu n'a pas changé. Exactement ce qu'on attend d'un feed en prod.

Trois middlewares couvrent les besoins HTTP classiques d'un flux RSS en production. Ils s'empilent dans un ordre précis — CORS en premier (le plus externe), puis le cache, puis le header de génération (le plus interne). Chacun ne touche que les réponses RSS et ignore silencieusement le reste. Votre API JSON continue de fonctionner normalement.

Ajoute un header X-Generator configurable sur chaque réponse RSS. C'est utile pour le debugging, le monitoring, et surtout pour identifier quel serveur a produit un feed dans un environnement distribué. Les réponses non-RSS (JSON, HTML, etc.) passent sans modification — le middleware détecte le Content-Type et n'intervient que sur application/rss+xml.

Gère le caching HTTP conditionnel. À chaque réponse RSS, il calcule un hash SHA256 du body et l'attache comme ETag. Si le client renvoie ce tag dans un If-None-Match, et que le contenu n'a pas changé, le middleware court-circuite la réponse avec un 304 Not Modified — zéro body, zéro travail de génération côté serveur.

Il ajoute aussi un Last-Modified (date de génération) et un Cache-Control: public, max-age=N configurable via CacheControlDuration — en minutes, heures, ou secondes selon vos besoins.

CORS complet avec gestion du preflight OPTIONS. Par défaut, il autorise toutes les origines (*) avec un max-age de 86400 secondes. Vous pouvez restreindre à une origine spécifique si votre cas d'usage l'exige. Le preflight retourne un 204 No Content sans body — exactement ce qu'attend un navigateur moderne.

podcastFeed() est une extension sur Application et RoutesBuilder qui enregistre un GET avec encodage automatique du PodcastFeed en XML. Ça supporte les chemins statiques et les paramètres dynamiques, exactement comme les routes Vapor que vous connaissez déjà.

En interne, FeedResponseEncoder convertit le PodcastFeed en Response avec le bon Content-Type, le pretty-print si configuré, et passe le relais aux middlewares pour les headers HTTP. Si vous préférez garder le contrôle total, req.feedResponse(feed) et Response.xml("...") sont aussi disponibles.

Pour un podcast avec 500 épisodes, servir les 500 à chaque requête n'a aucun sens. FeedPagination extrait les paramètres limit et offset de la query string et les clampe dans des bornes raisonnables. Pas de limite à 10 000 par erreur, pas d'offset négatif qui ferait planter votre requête SQL.

Pour les catalogues vraiment massifs où même la pagination ne suffit pas, StreamingFeedResponse génère le XML par chunks et le streame en Transfer-Encoding: chunked — le serveur n'a jamais besoin de garder le feed entier en mémoire. Parfait pour les plateformes qui hébergent des milliers d'épisodes.

Trois protocoles Swift purs transforment vos types en feeds. Attention : ce ne sont pas des protocoles Fluent — ils marchent avec n'importe quel type, struct ou class. C'est juste un contrat simple : vous implémentez une méthode to*(), et la lib sait convertir.

Quand vous publiez un épisode, les agrégateurs ne vérifient pas votre feed en continu — ils attendent un signal. Podping est ce signal. PodpingNotifier envoie un webhook HTTP POST pour prévenir l'écosystème qu'un feed a changé. Simple, efficace.

L'audit par lot expose un endpoint qui score plusieurs feeds en parallèle via le FeedAuditor de PodcastFeedMaker. Il suffit de passer les URLs en query string — chaque feed est récupéré, parsé, analysé, et noté. Pratique pour monitorer la qualité d'un catalogue entier.

La réponse JSON contient le score (0-100), la note lettrée (A à F), et le nombre de recommandations pour chaque feed. On a testé avec de vrais feeds en production pendant le développement — un Simplecast a obtenu un D/68 avec 9 recommandations, un Megaphone qui renvoyait du HTML au lieu du RSS a logiquement pris un F/0. La réalité du terrain.

Le core de PodcastFeedVapor n'a aucune dépendance sur Redis ou sur Vapor Queues. Deux targets optionnels ajoutent ces capacités pour les déploiements qui en ont vraiment besoin.

FeedCacheStore définit un contrat simple : stocker, récupérer, invalider. L'implémentation Redis utilise SETEX (set with expiry) et SCAN pour l'invalidation par pattern. Le tout se branche en une ligne dans votre config :

Pour les feeds lourds ou les régénérations planifiées, FeedRegenerationJob s'intègre dans Vapor Queues. Vous implémentez un handler, vous l'enregistrez, et vous pouvez dispatcher des jobs de régénération depuis n'importe quel handler de route.

Le streaming XML de la 0.1.0 résolvait le problème mémoire sur les gros catalogues. Mais chaque requête regénérait le feed from scratch. StreamingCacheResponse combine les deux : le XML est streamé au client ET caché simultanément. La première requête génère et stocke, les suivantes sont servies depuis le cache avec un ETag SHA256.

FeedCacheStore est un protocole — vous branchez le backend que vous voulez. InMemoryFeedCache est fourni pour le dev et les tests, RedisFeedCache pour la production.

Première requête : Transfer-Encoding: chunked, pas d'ETag — le XML est généré et streamé en temps réel. Deuxième requête : Content-Length fixe, ETag SHA256, servi depuis le cache. Le client peut ensuite envoyer un If-None-Match pour obtenir un 304.

Le target PodcastFeedVaporMetrics s'appuie sur swift-metrics d'Apple — backend-agnostique, vous branchez Prometheus, StatsD, Datadog ou n'importe quel collecteur compatible. FeedMetricsMiddleware s'ajoute en premier dans la stack middleware et enregistre automatiquement chaque requête feed.

Le préfixe pfv_ est configurable via FeedMetricsConfiguration. Le gauge des streams actifs est un actor dédié (FeedActiveStreamsGauge) qui s'incrémente quand un stream démarre et se décrémente à la fin — pas de lock, pas de race condition.

La 0.1.0 avait PodpingNotifier pour les webhooks HTTP sortants. La 0.2.0 ajoute un canal WebSocket entrant : les clients se connectent, s'abonnent à des feeds spécifiques, et reçoivent des notifications push quand un feed est mis à jour. Les deux mécanismes coexistent — webhook pour notifier les agrégateurs, WebSocket pour notifier vos propres clients.

Côté client, la communication se fait en JSON avec 5 types de messages : welcome à la connexion, subscribe/unsubscribe pour filtrer, subscribed en confirmation, et notification pour les mises à jour. Un client sans filtre reçoit tout ; un client abonné ne reçoit que les feeds qui l'intéressent.

Pendant le développement, on a construit un serveur de test complet pour valider chaque fonctionnalité avec de vrais appels HTTP. Le repo inclut un script qui le génère automatiquement comme projet Vapor autonome — pratique pour voir comment tout s'assemble.

Le serveur expose 11 endpoints qui couvrent toutes les fonctionnalités de la lib : feed statique, feed riche avec métadonnées Podcast NS 2.0, feed dynamique avec pagination, audit par lot, health check, CORS preflight, streaming cache avec ETag, WebSocket Podping en temps réel, et métriques swift-metrics.

Chaque fonctionnalité a été testée avec curl sur un vrai serveur Vapor tournant en local. 24 scénarios au total — 12 vérifications statiques et 12 tests fonctionnels live incluant streaming cache, WebSocket Podping et métriques. Quand on dit que ça marche, c'est parce qu'on l'a vraiment fait tourner.

Un détail d'architecture qui mérite d'être mentionné : dans le sample server, la construction des feeds (Feeds.swift) est séparée du point d'entrée Vapor (App.swift). Pourquoi ? Un conflit de noms entre le Channel de PodcastFeedMaker et le Channel de NIO (le runtime réseau de Vapor). En gardant les imports séparés, le compilateur résout les types sans ambiguïté. C'est documenté dans le projet parce que tout développeur qui mélange les deux imports tombera dessus tôt ou tard.

282 tests répartis dans 55 suites sur 4 targets. Couverture globale de 93.85% — en hausse de +3.6% par rapport à la 0.1.0. Le core monte à 99%+, les queues à 98.1%. Redis est plus bas (27.3%) parce que les tests d'intégration nécessitent un serveur Redis réel, mais le protocole FeedCacheStore est entièrement testé via un mock.

Chaque feature a ses showcase tests qui servent aussi de documentation exécutable. Les exemples de code dans le DocC et dans cet article sont tirés de ces tests — ce qui est écrit ici a été compilé et exécuté.

Quatre produits sont disponibles. Importez le core, et ajoutez Redis, Queues ou Metrics uniquement si votre déploiement les utilise vraiment :

Les specs sur lesquelles s'appuie PodcastFeedVapor, via PodcastFeedMaker :