Número 70
4 de outubro de 2023

O plan

Eu non son un artista plástico (unha vez quixen facer un sapoconcho de plastilina e acabei facendo un biscáncer), pero penso que, antes de faceren unha escultura, normalmente fan bosquexos sobre o que queren facer.

Un debuxo dunha casa que mestura varios estilos.Os construtores non tiñan un plan.

Tampouco son un arquitecto, pero dáme a impresión de que, antes de faceren un edificio, teñen unha idea máis ou menos aproximada de para que vai servir, o aspecto que vai ter, o seu número de pisos, etc.

Polo tanto, pode que sexa conveniente facer uns poucos plans antes de me poñer a escribir o sistema de comentarios.

A cuestión máis importante é como amosar os comentarios onda cada artigo. Se o sistema de contidos da Folla fora unha aplicación web normal escrita en Java ou en PHP, sería moi doado: abondaría con engadir unhas poucas liñas á función que implementa a “vista de artigos”. Porén, a Folla non funciona así, senón que consiste nunha colección de ficheiros HTML estáticos que se rexeneran cada semana.

A solución é simple: abonda con usar un pouco de JavaScript. Podo meter en cada ficheiro HTML un script que faga unha chamada AJAX a un servizo web e insira os comentarios no lugar correcto. Desta maneira, só os comentarios son dinámicos, e a Folla segue a ser un sitio web estático, como antes.

Polo tanto preciso dun servizo web que teña “endpoints” para descargar o script e tamén para facer as chamadas AJAX necesarias para descargar os comentarios dun artigo e para engadir un novo comentario. Tamén vou precisar dunha función de previsualización e dunha interface de administración de comentarios.

Diagrama que ilustra os dous parágrafos de enriba.Ás veces, os diagramas teñen un número excesivo de frechas.

Os comentarios van precisar de estar gardados nalgún sitio, así que tamén vou precisar dunha base de datos. Como o meu servidor xa ten MariaDB instalado, vou usar iso e así xa está o traballo feito.

Vou poñer o servizo web nun contedor usando Docker e o meu servidor web actual vai facer de “proxy inverso” para darlle acceso. A base de datos está instalada no sistema, así que non vou usar Docker para ela; só teño que asegurarme de configurar todo de maneira que o meu servizo poida acceder a ela.

Seguramente tamén precise dun sistema de caché para gardar datos de sesión, o resultado de converter Markdown a HTML, e outros datos efémeros. Vou usar memcached, que non mola tanto como Redis pero chega ben para as miñas necesidades e tamén pode ir noutro contedor.

Diagrama que ilustra os tres parágrafos de enriba.

No referente ás linguaxes de programación e frameworks, vou escribir o servizo web en Go, que é a mesma linguaxe na que escribín o sistema de contido da Folla. Desta maneira hei poder reutilizar o código de conversión de Markdown a HTML, por exemplo. A parte do frontend aínda non a teño decidida, pero seguramente use Angular con TypeScript.

Para a planificación de capacidade, normalmente miraría cantas peticións por segundo espero recibir e calcularía o número de servidores do que preciso. Neste caso non recibo peticións por segundo (máis ben recibo peticións por día), así que chega e sobra co servidor que xa teño.

O plan de monitorización tamén sería moi simple, pero como xa me dá traballo dabondo monitorizar á nena para ver se chora e lle hai que cambiar o cueiro, vouno deixar de lado polo momento. E o meu plan de recuperación de desastres consiste en activar unha nova instancia en Linode e recuperar a copia de seguridade de onte.

Este é o plan que teño polo de agora. Que vos parece? Sumariades algo? Quitariades algo?

A ilustración desta Folla foi producida combinando varias imaxes producidas mediante intelixencia artificial.