API de consultation des vues Velog (bêta)

Contexte de développement et idée d’implémentation

• Je voulais connaître le nombre de vues des articles publiés sur Velog, mais devoir me connecter à chaque fois pour le vérifier était pénible
• Il aurait été possible de faire du reverse engineering de l’API interne de vues de Velog, mais cela risquait d’être fastidieux et peu extensible (par ex. pour des notifications de visite)
• Cela m’a rappelé les anciens services de messagerie coréens qui proposaient une confirmation de lecture à l’aide d’images pixel
• Velog prend en charge la rédaction d’articles en syntaxe Markdown
• Les navigateurs ne bloquent pas un simple appel d’image, même sur un domaine cross-site
• En insérant une image transparente de 1x1 pixel dans un article, il devient possible d’enregistrer côté serveur un historique d’appels à chaque consultation de l’article
• La plupart des articles des utilisateurs de Velog ne dépassent pas 1 000 visiteurs par jour. Pour ce niveau de trafic, Workers KV suffit largement
• Cela ne se limite pas à Velog : toute plateforme prenant en charge l’insertion d’images via Markdown (et permettant de servir des images depuis un domaine utilisateur) peut l’utiliser

Fonctionnement

• En attribuant une valeur d’identification (slug) à l’image, puis en servant la réponse via des Workers programmables plutôt qu’un CDN, on peut utiliser cette valeur comme Key prefix dans KV pour enregistrer l’historique des appels et obtenir simplement les pages vues
• En utilisant la fonction de Hash sur la date, l’ip, le userAgent et la valeur d’identification de l’image, on peut gérer un minimum de déduplication des visites
  • HASH : hachage 128 bits basé sur SHA-256, encodé en base64url (22 caractères).
  • KEY : view:${slug}:${hash}.
  • VALUE : UserAgent, Date...
• Le plan gratuit de Workers KV prend en charge 1 000 PUT et LIST par jour.
  • PUT : permet d’enregistrer les informations de comptage de 1 000 visiteurs par jour
  • LIST : permet de fournir les informations de pages vues pour plus de 1 000 consultations par jour
• Les requêtes de consultation des pages vues utilisent la commande LIST : il suffit de récupérer les éléments avec la valeur d’identification (slug) comme prefix, puis de les compter simplement
  • Les pages vues n’ayant pas un fort besoin de temps réel, un cache approprié de la réponse permet de traiter plus de 1 000 requêtes par jour

Limites

Comme l’objectif était de développer rapidement, l’utilisation de KV, qui reste un stockage simple, entraîne les limites suivantes.

• Eventual consistency : les requêtes PUT de Workers KV ne sont pas en temps réel. Si le temps réel est indispensable, il faut utiliser Durable Objects(DO).
• Dépendance à LIST : cette méthode de comptage avec la commande LIST devient plus lente avec le temps à mesure que le nombre de KEY à récupérer augmente (en supposant que les pages vues continuent d’arriver régulièrement). Il faut envisager de mettre à jour régulièrement la structure de stockage avec une tâche Cron, ou d’utiliser DO ou Analytics Engine.

Fonctionnalités prévues

Je compte ajouter au plus vite les fonctionnalités suivantes.

• Tri par date : en utilisant le Unix Time, comme dans Créer une API serverless de commentaires de blog en 30 minutes, il sera possible de fournir une liste triée par sessions les plus récentes
• Sécurité de l’API : prise en charge prévue via l’ajout d’un middleware. Utilisation prévue de l’en-tête HTTP Authorization
• Rate Limit : pour les utilisateurs Velog populaires, il faut prévoir une protection contre les requêtes malveillantes de personnes aveuglées par l’occasion et la jalousie. Comme cela ne me concerne probablement pas, ce sera sûrement ajouté en dernier...
• Recherche : prise en charge prévue via l’ajout d’une API
  • Date : recherche par date précise ou par période. Nécessite une modification de la structure des KEY
  • Session : recherche d’informations sur l’activité d’une session précise. Actuellement, les informations de session sont valables une journée pour chaque article. Un examen de la politique de protection des données personnelles est nécessaire
  • Navigateur/OS : sera fourni à partir des informations parsées depuis le UserAgent. Ce ne sera pas très précis, mais suffisant pour se faire une idée générale
• API de service : l’API sera proposée sous forme de service afin que n’importe qui puisse l’utiliser facilement via vérification par e-mail + émission d’une clé privée
  • Webhook : envoi d’une requête POST lorsqu’un événement de page vue se produit. Cela permettra des notifications via Slack, très apprécié des développeurs
  • E-mail : une fonctionnalité de notification classique mais pratique pour les utilisateurs qui ne veulent pas gérer de webhook
  • Custom campaign : fourniture d’une valeur d’identification d’image (slug) intégrant des événements configurés (par ex. atteindre un certain nombre de vues)

Ajout

• Pour ceux qui s’intéressent au fonctionnement interne, veuillez consulter Journal de développement de l’API de consultation des vues Velog, à partir d’un pixel 1x1.
• La méthode d’installation et de déploiement, la référence API détaillée et l’ensemble du code sont disponibles dans le dépôt Github.