Read in English.

Contexto y antecedentes:

Para entender cómo surgió la idea y se programó el sitio web de Plaudere, miro hacia atrás y recuerdo todas las experiencias previas de las que formé parte: la curiosidad acumulada, los intentos que no salieron del todo bien, y aquellas herramientas que en un momento parecían encajar, pero que con el tiempo se replantearon hasta que la idea terminó convirtiéndose en la base de algo diferente. En mi caso, la historia de Plaudere está profundamente conectada con mi manera de acercarme a la informática a lo largo de los años, con mi etapa profesional, con los cambios que viví en distintas empresas y lugares y, también, con una parte de mi vida que siempre estuvo presente: mi gusto por la música y la creación musical.

Fue a finales de los años 2010 y principios de los 2020 cuando empecé a entender la programación de una web tanto a nivel de backend como de frontend. Pero llegar hasta ahí no fue algo repentino. Antes de poder programar una web como Plaudere, tuve que construir una base muy concreta: primero entender cómo funciona el software, después comprender los fundamentos de las bases de datos, luego aprender a usar diferentes tipos de lenguajes, desde el pseudocódigo, pasando por lenguajes tipo script como VBA en los inicios, hasta lenguajes de programación como JavaScript, lenguajes de consulta como SQL y lenguajes de marcado como HTML y CSS, y más tarde aprender cómo se analiza, diseña y materializa una idea de aplicación desde el concepto inicial hasta el prototipo, desde el primer intento hasta la mejora continua, desde una versión inicial hasta otra más madura, y así sucesivamente.

Ese camino, por supuesto, no suele ser lineal. Muchas veces implica cambiar de enfoque, eliminar funciones, añadir otras nuevas, reescribir partes enteras del proyecto, cambiar herramientas, ajustar la arquitectura y volver a empezar casi desde cero, pero con más criterio y un poco más de experiencia. Una formación formal en la materia ayuda mucho, claro que sí. Aunque tenía conocimientos de software y de diseño, en muchas etapas de mi vida no me quedaba otra que recorrer el camino más largo. Aprendía con tutoriales, con cursos, con libros, con pruebas, con errores, con correcciones y con paciencia. A veces confiaba demasiado en una herramienta o en un enfoque; otras veces replanteaba todo, entendía que algo no funcionaba y volvía a empezar.

Mirándolo ahora, pienso que ese proceso fue parte esencial de lo que hoy es Plaudere. Y, curiosamente, después de programar la web, también me permite hablar de ella y del propio proceso que la hizo posible. Mis conocimientos sobre desarrollo, en realidad, no comenzaron con Plaudere. Antes hubo muchos intentos por crear aplicaciones basadas en bases de datos e interfaz. Creo que siempre ha existido en mí una misma obsesión: aportar algo útil. Crear, ya sea en el trabajo o en la vida personal, una aplicación que otras personas vean como algo valioso, que les facilite algún aspecto de su vida o de su trabajo, y que les permita hacer algo un poco mejor, un poco más rápido o con más claridad.

Creando mis primeras aplicaciones:

Esa idea de ayudar a otras personas con una aplicación se materializó por primera vez en unas prácticas profesionales que hice a mediados de los años 2000 en una empresa de cadena de supermercados. Recuerdo bien aquella etapa porque fue uno de los primeros momentos en los que empecé a entender el valor real del software aplicado. En aquel tiempo cursaba el cuarto año de ingeniería industrial y buscaba prácticas. Finalmente, encontré una empresa que necesitaba un becario de marketing en Lima.

Mi trabajo consistía en colaborar con un responsable que analizaba datos transaccionales de los supermercados para generar reportes sobre clientes frecuentes y evaluar su respuesta a distintas acciones promocionales. Al principio, la experiencia fue compleja. Mi nivel de Microsoft Excel era limitado y me resultaba difícil transformar datos transaccionales en información estructurada, visual y agregada en forma de KPIs. Además, el trabajo era altamente repetitivo, ya que los reportes se basaban en estructuras que se actualizaban periódicamente con los mismos formatos. Una parte importante del tiempo se dedicaba a tareas manuales de preparación y actualización en Excel.

Esta situación me llevó a analizar dos aspectos concretos del problema. El primero era entender la lógica de los KPIs: cuáles eran realmente relevantes, cómo se calculaban, qué nivel de agregación tenían, qué datos los alimentaban, cómo se estructuraban las plantillas y qué errores o redundancias podían aparecer en ese flujo de trabajo. El segundo era reducir el tiempo dedicado a tareas manuales para poder centrarme más en el análisis.

Fue en ese contexto cuando descubrí que Microsoft Excel incluía un lenguaje de scripting integrado, VBA, que permitía automatizar acciones mediante código. Esto hacía posible ejecutar múltiples operaciones con un solo comando, replicando tareas manuales como la modificación de celdas, el cálculo en memoria, la actualización de tablas dinámicas o la generación de visualizaciones.

Sin darme cuenta, estaba entrando en un ámbito que más adelante se convertiría en la base de mi trabajo con datos. Con el tiempo, utilicé frameworks de gestión de datos, servicios en la nube y plataformas de dashboards más avanzadas. Sin embargo, esta primera experiencia fue clave porque introdujo un principio fundamental: una solución no es suficiente si solo funciona técnicamente; también debe ser comprensible y utilizable por el usuario final.

Al principio, la automatización de los KPIs mediante procesos de refresco en Excel me ayudaba principalmente a mí, ya que reducía el tiempo operativo y me permitía centrarme en el análisis. Sin embargo, su adopción no fue inmediata. Fue necesario explicar el cambio de enfoque del reporte y ajustar la forma en que el equipo interactuaba con el dashboard. Con el tiempo, el equipo empezó a valorar el rediseño del cuadro de mando y las capacidades que ofrecían las macros, como ajustar parámetros de cálculo, modificar visualizaciones, resaltar valores clave y actualizar distintos conjuntos de datos de forma más eficiente.

Posteriormente, al aprender VBA de forma autodidacta y mediante formación externa, pude construir una interfaz básica con botones que permitían navegar entre secciones del informe actualizado. También incorporé pequeñas mejoras como cambios dinámicos en cálculos, navegación por secciones y mensajes informativos. Aunque era una solución sencilla, permitió que otros miembros del equipo, incluido el responsable del área, empezaran a utilizarla para profundizar en el análisis de los datos.

Aprendizaje continuo desarrollando aplicaciones:

A partir de ahí, hice soluciones similares en una empresa de seguros durante mis prácticas, y también en una empresa de servicios generales, además de otras experiencias en el departamento de compras de una empresa de telecomunicaciones. En todos esos contextos fui creando macros de Excel cada vez más visuales, más limpias y con menos detalles visibles sobre cómo estaban construidas. También fui guardando metadatos sobre el uso, conectándome a bases de datos como Access y registrando o consultando la información que usaban el aplicativo o la macro de Excel.

A finales de los 2000 y principios de los 2010, al menos en los entornos corporativos en los que yo trabajaba, Microsoft Excel tenía muchísimo poder. Y más aún si el uso se parecía más al de una aplicación que al de una simple hoja de cálculo. Los equipos con los que colaboraba ganaban rapidez, los datos se recopilaban de forma más estructurada y se minimizaban errores de cálculo al mostrar los resultados. Claro que había iteraciones, cambios de versión y ajustes continuos, pero aun así siempre veía con mucha satisfacción que estas aplicaciones en Excel ayudaban de verdad.

Me interesó tanto este tema que terminé haciendo mi tesis de pregrado en ingeniería industrial sobre cómo simplificar el marco de análisis y desarrollo de aplicaciones para que áreas y usuarios de negocio pudieran aplicar esos principios y desarrollar rápidamente aplicaciones complejas que automatizaran el análisis de datos y la interpretación de resultados. Además, también colaboré como asistente de docencia en la asignatura de Análisis y Diseño de Sistemas de la universidad en la que me gradué, donde pude profundizar y consolidar mis conocimientos hasta principios de los años 2010.

La primera toma de contacto con el desarrollo web:

Hasta ese momento, mi experiencia se centraba en un conjunto limitado de herramientas: VBA, macros de Excel, bases de datos en Access y conocimientos de análisis y diseño de sistemas para construir aplicaciones combinando estos componentes. Sin embargo, en un rol posterior dentro de una empresa de telecomunicaciones, en el área de atención al cliente y gestión de reclamos, el volumen de datos comerciales que debía analizar para entender el origen de los problemas me llevó a trabajar con otro tipo de soluciones.

En ese contexto empecé a utilizar Visual Basic (no confundir con VBA), por lo que ya no contaba con un entorno predefinido para la interacción con el usuario. Era necesario construir una aplicación completa desde cero, definiendo elementos como la interfaz, el tamaño de ventana, los botones, el flujo de navegación, el proceso de instalación, las librerías, los mecanismos de autenticación y las capas de seguridad. Además, una parte esencial de la aplicación consistía en la integración con bases de datos como Microsoft SQL Server, utilizando una copia estructurada de datos de productos contratados por clientes, generada por un proceso interno del equipo de IT. Sobre esa base, los analistas añadían información complementaria no registrada en el sistema principal del departamento, lo que permitía generar correcciones operativas en el proceso de atención.

Esta aplicación fue bien recibida y terminó integrándose como una herramienta clave dentro del flujo de resolución de reclamos, mejorando la eficiencia del proceso y reduciendo incidencias repetitivas.

Más información sobre esta experiencia en gestión de reclamos en la publicación "Anticipar el reclamo del cliente".

Fue en ese momento cuando ocurrió un cambio importante en mi forma de entender el desarrollo de software. Dentro del mismo entorno, otros miembros del equipo propusieron una alternativa distinta: en lugar de Visual Basic, plantearon construir una aplicación web utilizando un servidor Apache y PHP, conectándose a la misma base de datos en SQL Server. El objetivo era ampliar el alcance de la solución, ya que la aplicación de escritorio tenía limitaciones de compatibilidad y distribución en los equipos de la organización.

La migración hacia una aplicación web permitió extender el uso de la aplicación a más usuarios y mejorar su integración en el trabajo diario del equipo de analistas. En términos prácticos, esto facilitó la estandarización del proceso de corrección de facturas y contribuyó a reducir el volumen de reclamos recurrentes.

Hasta ese momento, las aplicaciones web seguían siendo para mí algo técnicamente interesante, pero poco explorado en la práctica. Tuve una primera exposición al código en PHP, HTML y CSS, y participé de forma limitada en algunos aspectos del desarrollo. Poco después, y antes de iniciar un MBA en Bélgica tras ser admitido en una escuela de negocios, fui testigo del despliegue de esta solución dentro de la organización y de su evolución posterior.

Recuerdo observar cómo una aplicación web podía ejecutarse directamente en un navegador, conectarse a una base de datos y operar dentro de los flujos internos de la empresa. Esa experiencia cambió mi percepción sobre la arquitectura de software, ya que hasta ese momento mi enfoque estaba centrado en aplicaciones de escritorio y automatización local.

Sin embargo, en aquel periodo no profundicé más en el desarrollo web. Mi atención estaba orientada hacia una transición hacia el ámbito de negocio y gestión, no porque hubiera perdido interés en el desarrollo, sino porque buscaba ampliar mi perfil profesional. Años más tarde volvería a retomar ese camino, esta vez con una perspectiva más amplia, incorporando tecnologías web modernas y un enfoque más cercano al estado actual del desarrollo de software. Finalmente, ese recorrido terminaría convergiendo en la creación de la web Plaudere.

Consolidando el desarrollo de aplicaciones:

La informática estuvo prácticamente dormida en mí durante casi toda la década de 2010. En el MBA aprendí muchísimo sobre distintas materias relevantes para la gerencia general de una compañía. Y aunque estuve trabajando en unas prácticas en una empresa que hacía research sobre el potencial de mercado de un nuevo producto tecnológico, fue inevitable presentar los resultados de una simulación de costes mediante automatizaciones hechas con VBA y Excel, lo que me facilitaba mostrar resultados e iterar con diferentes escenarios financieros teniendo en cuenta la optimización de los repuestos de los productos mediante un modelo Solver de programación lineal.

A eso se sumó una nueva experiencia en logística en Lima, donde desarrollé modelos de pronóstico y un proceso basado en automatizar los cálculos e integrarlo en los procesos de abastecimiento. Y todavía hubo más: en dos experiencias sucesivas en España, una en una empresa editorial y otra en una agencia de medios, seguí necesitando mi experiencia en VBA porque resultaba muy útil para organizar y presentar datos de distintos negocios.

En resumen, durante una buena parte de mi vida profesional, VBA, Excel, Access, MySQL, SQL Server e incluso AutoIt y VB fueron las herramientas que utilicé con más frecuencia. Siempre estaba conectado de una u otra forma a los datos del negocio, y siempre aplicaba una capa de automatización de cálculos y presentación de información, ocultando opciones y automatizaciones mediante botones y una interfaz que, con los años, se fue volviendo más sencilla y más precisa. Incluso utilizaba con ingenio los servidores donde alojábamos los datos para poder garantizar una concurrencia viable, sin romper la aplicación y minimizando errores técnicos.

Primeros pasos en el desarrollo web:

Sin embargo, fue a finales de los años 2010, ya en la empresa editorial, cuando volví a recordar aquella experiencia en telecomunicaciones en la que había visto que aplicaciones similares, e incluso más robustas, podían desarrollarse usando tecnologías web. Por supuesto, existía una barrera de entrada importante, porque implicaba entrar en más detalles técnicos sobre cómo funcionan esas tecnologías, y en mi experiencia no había necesitado aprenderlas antes. Por eso no había desarrollado aún ese conocimiento.

Así que fui a la biblioteca de mi ciudad y tomé un libro para empezar a indagar sobre tecnologías web, pero pronto me di cuenta de que existía una barrera de conocimiento considerable que no había previsto. Cambiaba de libro constantemente sin lograr visualizar cómo sería capaz de desarrollar, en un periodo corto de tiempo, incluso una web básica que me demostrara a mí mismo que realmente podía dominar la materia. Varios libros y algunos cursos de desarrollo web después, finalmente conseguí completar ejercicios simples y empezar a comprender los fundamentos de HTML, CSS y JavaScript. Estas tecnologías resultaban bastante ajenas a mi experiencia previa con Visual Basic y SQL, pero de alguna forma sabía que podía lograrlo, pues era exactamente la misma sensación que había experimentado años atrás cuando comencé a indagar en VBA y Excel durante mis primeras prácticas profesionales.

La satisfacción de ver que mi primer código HTML, CSS y JavaScript se mostraba en el navegador fue una sensación que me impulsó a querer aprender más y más. Luego apareció la necesidad de aprender backend, porque HTML, CSS y JavaScript correspondían al frontend. Entender el lenguaje de etiquetas de HTML, los estilos en cascada de CSS y las nociones iniciales de JavaScript para controlar la lógica del frontend requiere tiempo, práctica y constancia. Pero una vez que adquieres un poco de conocimiento, el reto inmediato es trabajar en el backend.

Mis primeros prototipos demostraron que tenía muy poco interés en profundizar en backend, y en un inicio lo veía casi innecesario, confiando demasiado en la capacidad de procesamiento que lograba desde el frontend. La utopía de crear una web sin usar backend duró poco. Pronto entendí lo necesario que era administrar, por ejemplo, la conexión con la base de datos y, como mínimo, procesar los requests que llegaban de los usuarios para consumir la página. Al principio hacía un código mínimamente viable para atender los requests de la web, normalmente desde localhost. Entender la diferencia entre localhost y producción también puede ser confuso al principio, pero requiere paciencia y estudio de los fundamentos de cómo funciona una web para que, finalmente, desde una arquitectura básica de frontend y backend, puedas encontrar el camino que te permita materializar una idea de aplicación real.

Por lo menos, pasé un año estudiando, no a tiempo completo, sino en los momentos que tenía disponibles, todos esos componentes básicos de una web y la forma en que realmente funciona, así como la estructura del código que te permite crecer después. Y esto último es otro punto aparte, porque creo que entender cómo reacciona tu web ante la demanda, y cómo puede programarse de manera eficiente para que su crecimiento sea viable, requiere paciencia y práctica. Hay que pensar en el control, en la carga, en el estilo, en los datos que se registran, en las opciones, en la organización visual y en cómo opera el backend cuando recibe requests de lectura o escritura.

La realidad es que existen muchísimas opciones en desarrollo web. Me encontré con una infinidad de frameworks, herramientas, APIs, formas de estructurar la aplicación, maneras de organizar el código y, más adelante, también con temas de seguridad del contenido y del backend. Por eso creo que una decisión fue decisiva para poder avanzar: yo elegí usar la mínima cantidad posible de ayudas, como React o Bootstrap, por citar algunas, y tratar de aplicar una programación más abierta, usando JavaScript, HTML, CSS y Node con Express para el backend. Eso es lo que comúnmente se conoce como Vanilla JavaScript. En principio, es un estilo de programación que recomiendo cuando comienzas a aprender las bases, porque una vez que has creado algunos proyectos web, resulta mucho más sencillo saber qué herramientas puedes usar para agilizar el desarrollo y reutilizar código. Así que seguí por esa línea.

Motivación para el desarrollo web y el streaming:

Pero, reflexionando sobre la razón principal por la que comencé a interesarme en desarrollo web, me di cuenta de que mi motivación no era realmente dejar de usar VBA o Microsoft Excel. Lo que de verdad quería era entender cómo funcionaba la multimedia en la web y desarrollar alguna aplicación con esas capacidades. Claro, primero hay que aprender las herramientas básicas del desarrollo web, entre ellas las operaciones CRUD, es decir, crear, leer, actualizar y eliminar registros de una base de datos mediante una web, además de entender el ruteo de las diferentes páginas de una aplicación y algún tipo de programación en backend para personalizar las vistas que se entregan al usuario.

Sin embargo, cuando comencé a indagar sobre cómo funcionan aplicaciones como las videollamadas, los vídeos en streaming on demand como YouTube o las transmisiones en línea de audio y vídeo desde un streamer hacia una audiencia, me encontré completamente perdido al inicio. Encontré poca información en internet para entender los fundamentos del streaming aplicado al desarrollo web. No era información clara, o bien todo te llevaba a soluciones ya hechas usando servidores especiales de streaming. Entonces me preguntaba si era posible integrar capacidades de streaming en una página web convencional. Y fue justamente así como empecé, poco a poco, a desarrollar la idea de Plaudere.

Como tenía algunos conocimientos de música y además había tenido experiencias previas con algunas aplicaciones de streaming orientadas a músicos, entre ellas una llamada Sofa Session, aquella experiencia volvió a mi mente cuando estaba aprendiendo los fundamentos de cómo hacer que el sonido viaje inicialmente desde el emisor hasta el receptor mediante el uso de WebSockets, la Web Audio API y la API getUserMedia, que permitía conectarse a los dispositivos del usuario, capturar chunks y enviarlos mediante WebSockets al usuario receptor, para luego reproducirlos con un buffer básico y reproducción asistida por la Web Audio API. Gracias a eso pude aplicar los principios de una aplicación básica de streaming de audio. Creo que esa fue mi verdadera experiencia de “hola mundo” en este campo.

Tenía en mente la experiencia con Sofa Session y lo interesante que resulta conectar a músicos que comparten su música con otras personas. Entonces me propuse crear una aplicación que girara en torno a esa experiencia de streaming de audio, y posteriormente también de vídeo. Seguía aprendiendo sobre aplicaciones CRUD, pero también seguía pensando en cómo se podría mejorar el streaming de audio. Y más aún, uno de los grandes retos que me planteé, teniendo en cuenta la experiencia de Sofa Session, fue permitir una forma más económica y más rápida de lograr que al menos dos músicos pudieran combinar sus instrumentos y mostrar un sonido unificado a una potencial audiencia.

La idea de Plaudere:

Después de haber experimentado de forma aislada con tecnologías web, y tras algunos prototipos tipo walkie-talkie y redes sociales muy básicas en formato CRUD, me lancé a la aventura de dar forma a Plaudere. Inicialmente se llamó Willaitec, un nombre que venía del verbo comunicar, que es willay en quechua, unido a “tec”, como abreviatura de tecnología. Más tarde terminó llamándose Plaudere, que viene del latín y alude a aplaudir. En un momento dado se me ocurrió crear un botón de aplaudir en una de las primeras versiones de la web, y vi que una opción de aplaudir era en realidad equivalente a un like en las redes sociales. Esa idea me gustó, y así terminé nombrando el proyecto Plaudere.

Sin embargo, llegar a la versión actual no fue sencillo. Tuve que pasar por una evolución vertiginosa y en ocasiones complicada, pero siempre con el objetivo claro de dar forma a una aplicación híbrida, social y útil para ayudar a creadores musicales a construir transmisiones compartidas en directo.

Primer prototipo de Plaudere:

En cuanto vi que mi lógica para controlar el buffer de recepción de audio funcionaba, teniendo en cuenta la respuesta ante distintos errores de red de los usuarios y el impacto que eso tenía sobre un buffer mayor o menor, así como sobre la calidad de la información multimedia transmitida, sentí que ya estaba listo para crear mi primer prototipo de Plaudere entre 2020 y 2022. Usando Express para organizar las vistas, SQL para las operaciones CRUD de usuario y WebSockets para la transmisión en directo, y una vez que aprendí a mover información de un usuario a otro mediante WebSockets, le di vida a la primera versión de Plaudere.

Aquella primera versión era una web multipágina, con capacidad de crear transmisiones de audio en vivo y crear espacios, y permitía elegir el orden de transmisión de los usuarios. Es decir, el primero generaba un streaming de audio en directo y, si aparecía un segundo streamer, este absorbía la señal del primero y evitaba que llegara a la audiencia, mezclando ambos streams para emitir una señal final combinada que daba la impresión de que los dos músicos estaban transmitiendo juntos. Sin embargo, ese enfoque no permitía que el primer streamer escuchara al segundo.

Fue entonces cuando empecé a investigar más a fondo. Me di cuenta de que intentar construir una aplicación en la que el audio se transfiriera en tiempo real para que ambos streamers se escucharan, colaboraran y generaran una única transmisión de audio en directo implicaba, por un lado, una latencia casi nula entre el dispositivo de captura y el código, y luego una transferencia casi instantánea hacia el usuario receptor. Desde que se genera el audio hasta que se distribuye, ya sea a la audiencia o al segundo streamer, y desde ese segundo streamer de vuelta al primero y después a la audiencia, si se superan los 30 milisegundos de desfase se generan problemas serios de sincronización musical. En otras palabras, la diferencia o retardo de recepción del audio y la reacción es tan alta que desconcertaría a los músicos, y una combinación musical en directo dejaría de ser viable.

Eso fue algo que aprendí después de investigar sobre las posibilidades de crear una aplicación de live audio streaming para jamming. Y ante la complejidad y la inversión necesaria, opté por seguir evolucionando mi enfoque hacia algo parecido a una escalera de sonido: primero se genera el audio en el primer streamer, luego se mezcla en el segundo streamer antes de llegar a la audiencia. El resultado final es el mismo, pero he evitado la complejidad de la sincronización, que podría resultar muy costosa si quisiera aplicarse a nivel de potencia de cómputo y de dispositivos por parte de los usuarios.

Más información sobre la sincronización en directo en Plaudere en la publicación "Sincronización de contenido en vivo".

Primera versión de Plaudere.

Segundo prototipo de Plaudere:

El primer prototipo dependía de recordar el estado del usuario a través de las páginas URL de la web multipágina, y me resultaba retador conservar ese estado entre páginas. De hecho, no tenía ningún mecanismo de autenticación hasta el tercer prototipo. En aquella versión, el usuario indicaba cuál era su nombre y así podía identificarse en la aplicación y generar contenido, pero ese contenido se perdía porque la web no guardaba ninguna información: solo transmitía la información al vuelo.

Por eso empecé a pensar en una mejor versión de las páginas de la web, ya que la primera era muy básica, y me parecía que un modelo tipo SPA, es decir, single page application, podría simplificar el reconocimiento del usuario, su contenido y el intercambio de información del chat y del streaming que generara. Así nació un segundo prototipo.

Desarrollé ese segundo prototipo con la finalidad de aplicar el concepto SPA para controlar la web de Plaudere. Pero, hasta donde pude investigar y prototipar, al menos para el tipo de aplicación que yo buscaba, el frontend tenía que trabajar demasiado intensamente en mostrar las partes correspondientes de la web sin variar la URL principal, lo que implicaba más recursos del lado del usuario para renderizar la página, además de dejar menos margen para las operaciones de recepción y emisión de audio en live streaming.

Estuve al menos dos años, durante 2022 y 2023, intentando hacer más eficiente el código de la web en formato SPA, intentando llevar la mayor cantidad de operaciones posibles al worker de JavaScript de la web. Pero no logré un resultado satisfactorio. Mi código se volvió difícil de mantener y, dependiendo del dispositivo, la web no era viable de mostrar correctamente. Además, generaba confusión en los usuarios, porque no podían navegar hacia atrás fácilmente salvo que programaras una lógica específica para capturar el retroceso y llevar la aplicación a un estado anterior.

Al final no quedé satisfecho con ese prototipo, pero sí comprendí algo importante: la web tenía que ser ligera y las operaciones del frontend debían ser mínimas para evitar sobrecargarla. Y así fue como regresé a un enfoque multipágina, parecido al de la primera versión.

Segunda versión de Plaudere.

Tercer prototipo de Plaudere, versión vigente:

Volver a evolucionar el prototipo de single page application hacia un modelo multipágina fue dramático. Vi que no podía reutilizar mi código anterior salvo en la parte del streaming, y decidí entonces construir un tercer prototipo que realmente superara las barreras de las versiones anteriores. Esta vez el objetivo fue claro: por primera vez, conseguir autenticar al usuario mediante cuentas de Google o Microsoft, evitando que tuviera que crear una cuenta con email y password, con todo lo que eso suele implicar.

El tercer prototipo también buscaba mejorar la parte visual de las versiones anteriores, tratando de hacer la aplicación más amigable y más sencilla. Además, me impuse otro reto importante: los dos prototipos anteriores no conservaban información permanente del usuario, como sus preferencias, su nombre, su cuenta o el contenido que pudiera crear. Por eso reinstauré las operaciones CRUD, esta vez enmarcando la experiencia de streaming bajo un modelo tipo blog y artículo, de manera que, además de experimentar con live streaming de audio y, por primera vez, también de vídeo, los usuarios pudieran crear artículos y contenido estático que diera contexto a las transmisiones y a los espacios que construyeran.

Este tercer prototipo es el actual, y estuve trabajando en él durante 2024, 2025 y 2026. Es la versión vigente de la web. Actualmente usa cookies para registrar algunas preferencias básicas del usuario, como el modo oscuro o claro y el idioma de la interfaz, que ahora tiene tres versiones: inglés, español y catalán, en honor a la comunidad autónoma española en la que vivo. Además, utiliza una base de datos MongoDB que he empleado de forma experimental no solo para operaciones poco frecuentes como la creación y la edición de contenido, sino también para potenciar el streaming, mediante operaciones de servidor que consultan la base de datos de chunks generados en las transmisiones de forma recurrente y, mediante caché, distribuyen esa información a demanda hacia los usuarios que solicitan acceso a las transmisiones.

También permite al usuario no solo transmitir mediante sus dispositivos, sino también mediante contenido estático, como un audio o un vídeo. Y utiliza tecnología Markdown para permitir crear artículos con rich content, incluyendo estilos, títulos, subtítulos, bullet points, contenido embebido, comentarios, respuestas a comentarios y reacciones básicas. Además, incorpora autenticación mediante Google o Microsoft, de manera que el usuario no tenga que crear una nueva cuenta para usar Plaudere, sino que pueda acceder con el proveedor de su preferencia mediante cuentas existentes.´

Más información sobre el desarrollo de una aplicación de streaming en Plaudere en la publicación "Ingeniería de un prototipo de streaming".

Nuevos aspectos investigados en este tercer prototipo:

Hay nuevos aspectos que he investigado durante este tercer prototipo. Por ejemplo, en medio del desarrollo web, la irrupción de ChatGPT y, en general, de la inteligencia artificial generativa, que es un fenómeno reciente, me encontró trabajando en el segundo prototipo y migrando hacia el tercero. No tener una capa agéntica en un servicio puede convertirse hoy en un riesgo importante, porque se considera parte del estado del arte tecnológico actual. No estaba nada claro cómo podía aplicar una capa agéntica en este servicio, pero después de investigar a fondo las posibilidades de crear un agente básico durante 2024 y 2025, pude integrar un modelo sencillo usando Qwen 1.5 0.5B.

Más información sobre el agente IA de Plaudere en la publicación "Agente de IA para soporte al usuario".

Tuve que adaptar la interfaz para darle al usuario un espacio desde el que pudiera usar ese agente. En este caso, el agente sirve para resolver preguntas sencillas sobre la web, responder preguntas básicas sobre los artículos creados por los usuarios y también sobre los perfiles de usuario, limitando por supuesto la información que viene de las plataformas y dando acceso únicamente a la información que los usuarios suelen añadir a su perfil, como preferencias, reseñas y otros datos similares.

Conclusión y visión de futuro:

Estoy bastante satisfecho con este nuevo prototipo, al que además he tenido que ajustar para maximizar la compatibilidad con otros navegadores además de Chrome, como Edge, Firefox, Brave e incluso Safari. Safari presenta grandes retos a nivel de APIs, de JavaScript, de seguridad, de restricciones en el uso de workers y de opciones, y sobre todo a la hora de garantizar que el estilo CSS sea consistente entre navegadores. Las pruebas realizadas hasta la fecha indican que la web funciona en su versión actual, con todas sus funciones y restricciones.

Durante la puesta en producción de la web a través del dominio plaudere.com, empecé a detectar que existen robots de diferentes empresas tecnológicas que navegan por la web. Algunas de ellas encontraron mi web y comenzaron a revisar los enlaces HTML que existen en las distintas páginas, lo que permitió detectar algunas brechas de seguridad que pude solventar progresivamente. Así fui protegiendo la información de la web, aplicando también optimizaciones recurrentes a la base de datos MongoDB para asegurar una experiencia óptima, y manejando restricciones backend sobre las operaciones CRUD para evitar pérdidas involuntarias de información y también limitar los recursos de la web para que un ataque no pueda generar tráfico por encima de los límites del hosting.

Todos estos son aspectos importantes que merecen ser reflexionados cuando uno trabaja con una web. Y justamente ahí está una de las grandes lecciones de todo este proceso: evolucionar siempre la web, perfeccionarla, hacerla más eficiente y más segura para los usuarios. Plaudere no nació solo como una aplicación. Nació como una idea acumulada durante años, como una forma de unir informática, datos, música, colaboración y necesidad real. Y, al final, creo que eso es lo que le da sentido.

Esta es, en esencia, la historia de Plaudere. Pero también es la historia de cómo he ido aprendiendo a construir, a equivocarme, a corregir, a volver a empezar y a seguir avanzando hasta llegar a una web que hoy representa todo ese recorrido.