Prometí en la retrospectiva de la v1 que la v2 tendría una hoja de ruta real antes de escribir nada de código. Aquí está, el plan real, publicado para que mi yo futuro no pueda fingir que decía otra cosa. Esta entrada trata solo de lo que viene. Lo que ya se lanzó tiene sus propias entradas en este devblog, para eso está el devblog.
La idea central es ordenar por dependencia en lugar de por entusiasmo. Casi todo lo que quiero depende de unas pocas piezas fundamentales, así que esas van primero aunque sean las menos divertidas de construir:
+----------------------+
| email service | the keystone
+----------+-----------+
|
+------------+----------+-----------+-------------+
v v v v
password reset contact alerts reply notifications newsletter
+---------------------+ +---------------------+
| central log service | | backups (DB+media) |
+---------------------+ +---------------------+La ola uno es infraestructura. El servicio de correo va primero porque cuatro funciones separadas que quiero necesitan todas enviar correo, así que el correo se convierte en su propio pequeño servicio con un outbox duradero, y todo lo demás simplemente le pide que envíe cosas. Lo difícil del correo no es el SMTP, eso es una llamada a una librería. Lo difícil es todo lo que lo rodea: no perder un correo cuando el proceso se reinicia, no enviar el mismo correo dos veces cuando un reintento coincide con un envío exitoso, y la entregabilidad, el arte oscuro de los registros SPF, DKIM y DMARC que deciden si mi correo llega a una bandeja de entrada o a una carpeta de spam. Calculo que voy a pasar más tiempo leyendo documentación de DNS que escribiendo Go.
Las copias de seguridad están en la ola uno porque no tienen dependencias ni excusa. Lo difícil de las copias de seguridad no es hacerlas, eso lo puede hacer cron. Es demostrar que se pueden restaurar. Una copia de seguridad sin probar es una sensación, no una copia de seguridad, así que el plan incluye restaurar de verdad a una base de datos de prueba con cierta frecuencia y comprobar el resultado. Copias fuera de la máquina también, porque una copia de seguridad en el mismo disco que lo que respalda protege solo contra un tipo de fallo, y no el que da miedo.
El servicio de logging centralizado es el bicho raro honesto de la lista. Un blog personal no necesita uno, las tablas de errores de cada servicio ya hacen el trabajo. Lo estoy construyendo de todos modos porque los patrones que hay dentro son todo el punto: un shipper de outbox que agrupa filas hacia un destino central, reintenta cuando la red falla, y un consumidor que se mantiene correcto cuando el mismo lote llega dos veces. Son patrones que vale la pena aprender en un sistema donde el radio de la explosión es mi propio blog. Lo escribo aquí para no acabar sobrediseñándolo por accidente en algo con forma de empresa.
La ola dos es todo lo que necesita correo. El restablecimiento de contraseña suena trivial y está lleno de detalles delicados: tokens de restablecimiento que caducan y solo se pueden usar una vez, y respuestas que no revelan si una dirección de correo tiene una cuenta aquí. La verificación de correo va de la mano. Las alertas del formulario de contacto son el calentamiento fácil. Las notificaciones de respuestas a comentarios necesitan una forma de darse de baja por hilo, nadie quiere recibir correo para siempre solo porque comentó una vez. El boletín es la parte más profunda: consentimiento de los suscriptores, enlaces para darse de baja que siempre funcionan (esa parte es ley, no cortesía), y enviar lo bastante despacio para que mi único servidor pequeño no acabe en una lista negra.
La ola tres es la divertida. Un subidor masivo de fotos y una galería, porque este blog se está convirtiendo poco a poco en una colección de fotos de caminatas con un blog pegado. Partes difíciles: pasar cientos de archivos por una subida desde el navegador sin que un solo fallo arruine el lote entero, generar miniaturas en el servidor para que la galería no envíe fotos a tamaño completo al teléfono, y quitar los datos EXIF antes de publicar, porque una foto que lleva coordenadas GPS en silencio es una fuga de privacidad disfrazada de bonito atardecer. Las series de publicaciones también entran aquí, enlazar publicaciones en una colección ordenada, que es más una pregunta de modelado que de código.
La ola cuatro es alcance. ActivityPub es la pelea final: hacer que las publicaciones federen para que la gente pueda seguir este blog desde Mastodon. Significa actores, bandejas de entrada, bandejas de salida y firmas HTTP, y el folclore dice que cada servidor habla un dialecto ligeramente distinto de la especificación, así que la mayor parte del trabajo es depurar la federación con servidores que no controlo. Los webmentions son la versión de calentamiento más ligera de la misma idea. Un ayudante de traducción para los tres idiomas en los que corre este blog también entra aquí: traducir una vez al escribir y guardarlo (una vista de página nunca debe costar una llamada a la API), detectar cuándo cambió el original para que una traducción se pueda marcar como desactualizada, y hacer que la salida de la máquina siempre aterrice como borrador para que yo lo edite, nunca directo a publicación. Y la lectura sin conexión como PWA, donde la trampa famosa es la invalidación de caché sirviendo a los lectores un sitio desactualizado para siempre.
Cada una de estas se lanza como su propio cambio pequeño y terminado, no como una rama gigante de v2 que vive durante un mes. Si solo la ola uno sale bien, la v2 ya valió la pena. Lo aburrido primero, a propósito, por escrito. Que se me exija cumplirlo.