Vermutech #31

ene 19, 2025

Aquesta setmana hem afegit una funcionalitat nova al frontal del sistema: notificacions en temps real! Estan basades en Server Sent Events (SSE), un tema que vaig explicar al número 29. És veritat, és bastant més senzill que Websockets, però… també té els seus maldecaps. Aquí en tens uns quants que m’he trobat, amb les solucions corresponents:

En local tot funciona, però en producció no arriben missatges!
Això pot ser degut al buffering. Si utilitzes nginx com a servidor per balancejar i servir peticions, cal desactivar el buffering per la location dedicada a l’SSE.
Cada frontal obre una connexió permanent amb el servidor.
Si no tens una cua de connexions prou gran, pots quedar-te sense connexions disponibles. Una possible solució és configurar una location específica a nginx per a l’SSE i fer que aquest el gestioni una altra aplicació. Això et permetrà escalar o moure aquesta part sense impactar en l’aplicació principal.
Quan reinicio l’aplicació dedicada a SSE, el client no es reconnecta!
Tens dues solucions:
1. Afegeix intents de reconnexió al client. Tot i que ho fa automàticament, si rep un error 500 (com quan nginx no troba el backend), ja no ho torna a intentar.
2. Configura nginx perquè no consideri crítics els errors 500 en aquesta location.

Si et serveix d’ajuda, aquí tens un enllaç amb un exemple de configuració per nginx que pot ser útil.

Començo amb algunes recomanacions,

💾 Programari

Portspoof: Aquesta eina simula que els 65.000 ports de la màquina estan donant servei. Això dificulta molt la feina a possibles atacants que intentin escanejar quins serveis tens actius. A més, té una funcionalitat per fer un atac invers si detecta que algú està intentant explotar algun servei.

🤔 Curiositats

DOOM: The Gallery Experience transforma DOOM (1993) en una galeria d’art. Camina, observa peces artístiques i pren una copa de vi mentre explores aquest espai totalment reimaginat. 🎨🕹️

📦 Recursos

CSS Loaders: Una col·lecció infinita d’animacions per mostrar durant el temps de càrrega d’una pàgina. Totes fetes només amb CSS! Algunes són tan entretingudes que et quedaràs mirant-les més temps del necessari.

🌟 El concepte

Si alguna vegada t’has preguntat si hi ha patrons de software per a tot, la resposta és que sí, i n’hi ha de més i de menys coneguts. Avui et presento un patró que potser no és dels més famosos, però que resulta molt útil en situacions on cal fer grans canvis sense espantar ningú: el Strangler Fig Pattern. I no, no té res a veure amb plantes assassines… o potser sí? 🌱💻

El Strangler Fig Pattern és una estratègia de desenvolupament de programari que permet substituir sistemes antics per nous de manera progressiva i sense interrupcions significatives.

Aquest patró va ser introduït per Martin Fowler el 2004, inspirant-se en la manera com les plantes strangler fig creixen al voltant d’un arbre hoste i, amb el temps, el substitueixen.

Aquest patró és ideal per modernitzar sistemes heretats (legacy systems) que no es poden aturar ni substituir de cop. L’objectiu és construir funcionalitats noves en paral·lel amb les antigues, redirigint gradualment el trànsit i les operacions cap al sistema modernitzat fins que el vell es pugui retirar completament.

Com funciona?

Identificar components: Primer s’analitzen les funcionalitats del sistema existent i es decideix quins components es poden modernitzar.
Crear un intermediari: Es posa en marxa una capa (middleware) que permet redirigir les peticions dels usuaris, gestionant quines van al sistema vell i quines al nou.
Substitució progressiva: Es desenvolupen els nous components i es redirigeixen les operacions cap a aquests, una funcionalitat a la vegada.
Eliminació del sistema vell: Quan el nou sistema ja cobreix totes les funcionalitats, el sistema vell es pot retirar completament.

Avantatges del Strangler Fig Pattern

Reducció de riscos: No cal fer un llançament massiu; els canvis es poden introduir de manera controlada.
Flexibilitat: Permet desenvolupar amb tecnologies modernes sense haver de reescriure tot el sistema des de zero.
Interrupcions mínimes: L’usuari final no percep canvis dràstics ni disrupcions durant la migració.

Un exemple pràctic

Imagina una plataforma de comerç electrònic amb un sistema heretat per gestionar pagaments. Implementant el Strangler Fig Pattern, podries:

Mantenir el sistema antic mentre construeixes un nou mòdul de pagaments.
Redirigir només una part de les transaccions cap al nou mòdul per provar-lo.
Quan el nou sistema demostri ser fiable, transferir-hi totes les transaccions i desactivar l’antic.

Per fer-ho més clar, aquí tens un exemple senzill amb Python que simula aquesta transició:

class OldSystem:
    def process_data(self, data):
        # Funcionalitat antiga
        print(f"[Old System] Processing data: {data}")
        return f"Old result for {data}"

class NewSystem:
    def process_data(self, data):
        # Funcionalitat nova
        print(f"[New System] Processing data: {data}")
        return f"New result for {data}"

class Middleware:
    def __init__(self):
        self.old_system = OldSystem()
        self.new_system = NewSystem()
        self.transitioned_functions = set()

    def process_data(self, data, function_name):
        # Decideix si utilitzar el sistema nou o l'antic
        if function_name in self.transitioned_functions:
            return self.new_system.process_data(data)
        else:
            return self.old_system.process_data(data)

    def migrate_function(self, function_name):
        # Marca una funcionalitat com a migrada
        print(f"[Middleware] Migrating {function_name} to the new system.")
        self.transitioned_functions.add(function_name)

# Exemple d’ús
middleware = Middleware()

# Processament inicial amb el sistema vell
middleware.process_data("Task A", "function1")
middleware.process_data("Task B", "function2")

# Migració de la funcionalitat 'function1'
middleware.migrate_function("function1")

# Processament després de la migració
middleware.process_data("Task A", "function1")
middleware.process_data("Task B", "function2")

Aquest exemple mostra com redirigir les funcionalitats a mesura que es migrin al sistema nou, mantenint la compatibilitat i estabilitat durant tot el procés.

Per fer aquest procés encara més segur, existeixen tècniques com el Shadow Testing, que permeten validar el sistema nou sense afectar els usuaris finals. Ho explorarem en el pròxim número!

💖 Feedback

Si t’ha agradat i em vols ajudar, fes arribar aquest contingut a qui creguis que li pot interessar, i entra al canal de Telegram per comentar la publicació.

Vermutech newsletter