¿Cómo debería estructurar mejor mi aplicación web usando colas de trabajo [y Perl / Catalyst]?

Question

Estoy escribiendo una aplicación web usando el marco de Catalyst . También estoy usando una cola de trabajos llamada TheSchwartz .

Deseo utilizar una cola de trabajos porque deseo que la mayor parte del código específico de la aplicación se desacople del código de interfaz de la aplicación web.

Esencialmente, todo el sistema consta de tres componentes principales:

• GUI (interfaz web de Catalyst)
• Un rastreador
• Un "componente atacante" (la aplicación se está escribiendo para buscar vulnerabilidades XSS y SQLi en otras aplicaciones / sitios web)

Entonces, en teoría, la GUI crea trabajos para el rastreador que a su vez crea trabajos para el "componente atacante".

Actualmente tengo un Modelo en Catalyst que crea una instancia de un objeto TheSchwartz para que los Controladores en la aplicación web puedan agregar trabajos a la cola de trabajos.

También necesito crear algunas secuencias de comandos de trabajo que escuchen continuamente (/ verifiquen la base de datos) en busca de nuevos trabajos para que puedan realizar las acciones requeridas. Actualmente, el material específico de DB para TheSchwartz está en el Modelo en Catalyst y no creo que pueda acceder fácilmente a eso fuera de Catalyst.

No quiero duplicar los datos de conexión de la base de datos para la cola de trabajos de TheSchwartz en el Modelo y luego en mis scripts de trabajo. ¿Debo envolver la creación del objeto TheSchwartz en otra clase que se encuentre fuera de Catalyst y llamarlo en el Modelo que actualmente está instanciando el objeto TheSchwartz? Entonces también podría usar eso en los scripts de trabajo. ¿O debería tener los datos de la base de datos en un archivo de configuración e instanciar nuevos objetos de TheSchwartz cuando los necesite (dentro de Catalyst / dentro de scripts de trabajo)?

¿O acabo de pensar en esto?

Algunos enlaces a artículos de arquitectura de aplicaciones web también pueden ser útiles (nunca he creado uno de complejidad moderada antes ...).

Saludos

Answer 1

¿Está utilizando DBIx :: Class? La idea básica aquí se aplica incluso si no lo eres, pero voy a seguir adelante y asumir que sí.

Un modelo Catalyst debería ser un contenedor para otra clase, proporcionando el comportamiento suficiente para interactuar con Catalyst, y nada más. Por ejemplo, Catalyst :: Model :: DBIC :: Schema es solo un contenedor para DBIx :: Class :: Schema. Obtiene la configuración de Catalyst y la pasa a DBIC, inyecta los ResultSets en el espacio de nombres del Modelo (para que pueda hacer el $ c- > model ('DB :: Table') truco) , y luego se quita del camino.

La ventaja es que dado que todo el código importante se encuentra fuera de Catalyst :: Model, es completamente independiente de Catalyst. Puede cargar su esquema desde un script de mantenimiento o un trabajador de cola de trabajo o cualquier otra cosa, pasarle alguna configuración, decirle que se conecte y listo, sin invocar a Catalyst. Toda la información y la lógica que está en sus ResultSets y cualquier otra cosa que esté igualmente disponible fuera de Catalyst como dentro.

Answer 2

Si entiendo correctamente, su pregunta es "¿cómo puedo reutilizar mi conexión de base de datos fuera de Catalyst?".

Debería haber usado DBIx :: Class dentro de su aplicación Catalyst. Puede reutilizar los mismos archivos en cualquier otra aplicación. $ c- > mode ('DB :: MyTable') - > search (...) en Catalyst es lo mismo que esto fuera del catalizador:

my $schema = MyApp::Model::DB->new();
$schema->resultset('MyTable')->search(...)

Se puede llamar a cualquier modelo fuera de Catalyst como un paquete normal MyApp :: Model :: Library- > new (). Solo quiere asegurarse de no usar $ c como argumento.

Answer 3

Una de las cosas que debe observar es usar TheSchwartz :: Simple para crear trabajos en lugar de TheSchwartz en sí (que realmente solo necesita para procesar trabajos). Las ventajas son:

• Ligero (no es necesario cargar todo TheSchwartz en su aplicación Catalyst)
• Acepta un identificador de base de datos simple para conectarse a la base de datos, mientras que TheSchwartz esencialmente tiene su propia capa de envoltura de base de datos y querrá que le dé nombres de usuario y contraseñas y administre su propia conexión (que ha dicho que no quiere) hacer)