Skip to content

RubenPX/edaw

Repository files navigation

WebWorker Event Driven Architecture

La idea de este proyecto es crear un proyecto base donde se use una arquitectura basada en eventos para usarlo con WebWorker

¿Porque pensar como una libreria a parte y no como una aplicación única?

La ventaja de hacer una libreria, es que es totalmente agnostico al framework que se use. ya sea react, vanillajs, svelte, angular, etc... Esta libreria ofrece libertad para usarse.

Para que sea fácil para otros desarrolladores, he decidido usar el patrón de código Factory para construir las request. (Aqui un ejemplo) Esto tiene varias ventajas al respecto, siendo la más importante que el desarrollador no tenga que preocuparse de cómo tiene hablar entre el navegador y el webworker. Toda la libreria esta realizada de modo se puedan recibir eventos (tanto de resultados como de errores)

Estructura de proyecto

Todo siguiendo la opinión de CodelyTV (¿Que es la arquitectura Hexagonal?)

Aquí está un concepto de cómo se reparte el código y sus carpetas.
En este caso, la proposición es Que eres y que capa eres

Propuesta

Funcionamiento de la aplicación

El objetivo de este repositorio es unicamente dejar en un hilo a parte el procesamiento de datos. Para ello se simula un "servidor" en forma de WebWorker.

Aquá debajo, se define como se comunica el cliente (Navegador) con el Hilo a parte (WebWorker).

stateDiagram-v2
    state client {
        [*] --> preparedEvent: Builded request 
        preparedEvent --> processed
    }

    state ...observer <<fork>>

    state Worker {
        processed --> ...observer: Spread event
    }

    state client {
        ...observer --> [*]: Return to event source
        ...observer --> [*]: observer1
        ...observer --> [*]: observer2
        ...observer --> [*]: observer...
    }
Loading

Conceptos de esta plantilla

Esta plantilla diseñé un concepto que se basa en algunas ya hechas, pero con un algunos cambios. En este caso voy a expoer de como crear un handler para procesar un evento

La idea es sencilla de entender

El worker intercepta el mensaje, y busca un contexto. Una vez se haya encontrado un contexto, envia el mensaje al worker para que procese el metodo.

stateDiagram-v2
direction LR

[*] --> worker
worker --> context
context --> method
method --> [*]
Loading

Todo empieza en la inicialización del worker (Aqui se instancia las bases de datos y los contextos).

Una vez se recibe un evento, el worker lo publica como un evento de dominio y busca el contexto mencionado en el mensaje. Una vez se ha encontrado el contexto, se delega el mensaje a el contexto. Ahí, el contexto, busca el metodo que requiere y lo delega a un runner que es el que se encarga de procesar la solicitud del mensaje

Capas de la arquitectura y comunicación

  • View: Interfaz de usuario (Se encarga de gestionar la interacción con el usuario)
  • Route: Enrutador de eventos (Intermediario entre la vista y los controladores. Se encarga de enrutar los eventos)
  • Controller: Logica de la aplicación
  • Model: Gestiona los datos y el estado actual de la aplicación

Roadmap

  • Enviar y recibir eventos entre el worker y el browser
  • Permitir la observación de eventos
  • El control de errores, en consola, te referencia exactamente donde ha fallado el webworker en vez de mostrar un error generico
  • logs mejorados en consola (Para ver los eventos, requiere que tengas verbose activado en las devtools)
  • Auto completado de rutas usando typescript
  • A la hora de navegar código, con el ctrl + click te lleva a el metodo que lo ejecuta sin que vaya a las clases abstractas

Roadmap (Técnicas usadas)

La idea de este proyecto ha surgido de una necesidad en el trabajo. Organizar Código y optimizar la aplicación

Primero lo que pensé es en crear algo usando las técnicas de arquitectura hexagonal.

después explorando y haciendo pruebas, me di cuenta que era algo tedioso que ir moviéndose a diferentes niveles de carpetas, así que descubrí la técnica "Vertical Slice" que se aplica en arquitectura hexagonal

Mas tarde, decidí usar una tecnología que usan los navegadores que se llama Web Workers Api según una web muy relevante en el mundo del frontend, es compatible con el 98% de los navegadores. En resumen, consiste en dejar todo el trabajo de procesamiento separado en un hilo diferente. Es algo costoso al principio, pero vale la pena para mejorar la experiencia de usuario y evitar que la aplicación tengo micro cuelgues

Por último, para hacer que este trabajo sea totalmente agnóstico a cualquier framework web que se use, decidi convertir el proyecto en una librería

Opinión

Esta estructura de carpetas es una forma opinionada de como creo yo @RubenPX de cuál es la forma que mejor me parece a la hora de estructurar las carpetas y el estilo de código.

Library features

  • Hybrid support - CommonJS and ESM modules
  • IIFE bundle for direct browser support without bundler

About

Event Driven Design Worker

Resources

License

Stars

Watchers

Forks

Releases

No releases published

Packages

No packages published