API para consultar visualizaciones de Velog (beta)

Contexto de desarrollo e idea de implementación

• Tenía curiosidad por las visualizaciones de las publicaciones que escribí en Velog, pero da flojera iniciar sesión cada vez para revisarlas
• Podría hacer ingeniería inversa de la API interna de visualizaciones de Velog, pero parece más tedioso y menos escalable (por ejemplo, para alertas de visitantes)
• Me acordé de cómo algunos servicios de correo coreanos antes ofrecían confirmación de lectura usando imágenes de píxel
• Velog permite escribir publicaciones usando sintaxis Markdown
• Los navegadores no bloquean una simple carga de imagen aunque sea de un dominio cross-site
• Si insertas una imagen transparente de 1x1 píxel en la publicación, el servidor puede dejar registro de cada llamada cada vez que se vea la publicación
• La mayoría de las publicaciones de usuarios de Velog no reciben más de 1,000 visitantes al día. Para ese nivel de tráfico, Workers KV es más que suficiente
• No está limitado a Velog: puede usarse en cualquier plataforma que permita insertar imágenes con sintaxis Markdown (y servir imágenes desde un dominio del usuario)

Cómo funciona

• Después de asignar un valor identificador (slug) a la imagen, en vez de responder desde un CDN se usa Workers programable, y si se guarda el registro de llamadas usando ese identificador como Key prefix en KV, se puede obtener el page view de forma simple
• Si se crea una key con fecha, ip, userAgent y valor identificador de imagen usando una función Hash, es posible manejar al menos una deduplicación mínima de visitas
  • HASH: hash de 128 bits basado en SHA-256, codificado en base64url (22 caracteres).
  • KEY: view:${slug}:${hash}.
  • VALUE: UserAgent, Date...
• El plan gratuito de Workers KV admite 1,000 operaciones PUT y LIST por día.
  • PUT: permite guardar información de conteo de visitantes por 1,000 visitas al día
  • LIST: permite entregar información de page views por más de 1,000 al día
• La consulta de page views usa el comando LIST: basta con traer los datos usando el valor identificador (slug) como prefix y contarlos de forma simple
  • Como la consulta de page views no requiere tanta inmediatez, si se cachea adecuadamente la respuesta, se pueden procesar más de 1,000 solicitudes por día

Limitaciones

Como se usó KV, que es un almacenamiento simple, para desarrollar rápidamente, existen las siguientes limitaciones.

• Eventual consistency: las solicitudes PUT de Workers KV no son en tiempo real. Si realmente se necesita tiempo real, hay que usar Durable Objects(DO).
• Dependencia de LIST: el método de conteo usando el comando LIST se vuelve más lento con el tiempo (asumiendo que los page views siguen llegando) a medida que aumenta la cantidad de KEY que hay que recuperar. Habría que considerar actualizar continuamente la estructura de almacenamiento con tareas Cron, o usar DO o Analytics Engine.

Soporte planeado

Se planea agregar las siguientes funciones lo antes posible.

• Orden por fecha: usando Unix Time, el mismo enfoque utilizado para ordenar comentarios recientes en Crear una API de comentarios para blog serverless en 30 minutos, se puede ofrecer una lista ordenada con base en las sesiones más recientes
• Seguridad de API: se planea agregar soporte mediante middleware. Se usará el encabezado HTTP Authorization
• Rate Limit: si eres un usuario popular de Velog, puede haber personas cegadas por la envidia que envíen solicitudes maliciosas, así que hace falta una medida preventiva. Probablemente esto se agregue al final porque no aplica mucho en mi caso...
• Búsqueda: se agregará soporte mediante API adicional
  • Fecha: búsqueda por fecha específica o por rango de fechas. Requiere cambiar la estructura de la KEY
  • Sesión: búsqueda de información de actividad de una sesión específica. Actualmente la información de sesión es válida por un día para cada publicación. Hace falta revisar la política de protección de datos personales
  • Navegador/OS: se ofrecerá a partir de información parseada del UserAgent. Aunque no será muy preciso, sí permitirá una idea general
• API como servicio: se planea ofrecer la API en forma de servicio para que cualquiera pueda usarla fácilmente con verificación por correo + emisión de clave privada
  • Webhook: al producirse un evento de page view, se ofrecerá una solicitud POST. Hará posible enviar alertas usando Slack, que tanto les gusta a los desarrolladores
  • Correo electrónico: una función de notificación clásica pero práctica para usuarios a quienes les da flojera manejar webhooks
  • Custom campaign: se proporcionará un valor identificador de imagen (slug) integrado para eventos configurados (por ejemplo, alcanzar cierto número de visualizaciones)

Adicional

• Si les interesa la estructura interna de funcionamiento, consulten Historia del desarrollo de la API para consultar visualizaciones de Velog que empieza con un píxel de 1x1.
• El método de instalación y despliegue, la referencia detallada de la API y el código completo pueden revisarse en el repositorio de Github.