¿Cómo debo estructurar mejor mi aplicación web usando colas de trabajos [y Perl/Catalyst]?

Question

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

Estoy queriendo usar una cola de trabajos porque estoy queriendo la mayor parte del código específico de la aplicación desacoplado del código de la interfaz de la aplicación web.

Esencialmente todo el sistema consta de tres componentes principales:

• GUI (interfaz Catalizador web)
• Un rastreador
• Un "atacar componente" (la aplicación se está escribiendo para buscar XSS y vulnerabilidades SQLi en otros sitios) webapps/

por lo tanto, en teoría, la interfaz gráfica de usuario crea puestos de trabajo para el rastreador que a su vez crea puestos de trabajo para el "componente de atacar".

Actualmente tengo un modelo en Catalyst que ejemplifica un objeto TheSchwartz para que los controladores en la aplicación web puedan agregar trabajos a la cola de trabajos.

También necesito crear algunos scripts de trabajador de trabajos que escuchen continuamente (/ comprueben la base de datos) para nuevos trabajos para que puedan realizar las acciones requeridas. Actualmente, el material específico de DB para TheSchwartz está en el Model in Catalyst y no creo que pueda acceder fácilmente a eso fuera de Catalyst.

No quiero duplicar los datos de conexión de DB para la cola de trabajos de TheSchwartz en el Modelo y luego en los scripts de mi trabajador del trabajo. ¿Debería envolver la creación del objeto TheSchwartz en otra clase que se encuentra fuera de Catalyst y llamarlo en el modelo que está instanciando actualmente el objeto The Schwartz? Entonces también podría usar eso en los scripts de los trabajadores. ¿O debería tener los datos de la base de datos en un archivo de configuración y crear una instancia de los objetos TheSchwartz nuevos cuando los necesite (dentro de Catalyst/dentro de los scripts del trabajador del trabajo)?

¿O acabo de pensar en esto?

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

Saludos

Answer 1

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

Un modelo Catalyst debe ser un contenedor para otra clase, proporcionando el comportamiento suficiente para la interfaz 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 Model (para que pueda hacer el truco $c->model('DB::Table')), y luego se quita de en medio.

La ventaja es que como todo el código importante está fuera de Catalyst :: Model, es completamente independiente de Catalyst. Puede cargar su esquema desde un script de mantenimiento o un trabajador de jobqueue o cualquier otra cosa, pasarle alguna configuración, decirle que se conecte y se vaya, sin siquiera invocar Catalyst. Toda la información y la lógica que está en tus ResultSets y en cualquier otra cosa están igualmente disponibles fuera de Catalyst como adentro.

Answer 2

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

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

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

Cualquier modelo puede ser llamado fuera del catalizador como un paquete normal MiApl :: :: Modelo Biblioteca-> new(). Solo quiere asegurarse de no usar $ c como argumento.

Answer 3

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

• Ligera (sin necesidad de cargar la totalidad de TheSchwartz en su Catalizador App)
• Acepta un mango simple base de datos para conectarse a la base de datos, mientras que TheSchwartz esencialmente tiene su propio capa de envoltura de base de datos y quiere que le dé nombres de usuario y contraseñas y administre su propia conexión (que ha dicho que no quiere que haga)