我应该如何使用作业队列 [和 Perl/Catalyst] 最好地构建我的 Web 应用程序?

发布于 2024-08-09 01:58:00 字数 965 浏览 4 评论 0原文

我正在使用 Catalyst 框架 编写一个 Web 应用程序。我还使用名为 TheSchwartz 的作业队列。

我想要使​​用作业队列,因为我希望将尽可能多的应用程序特定代码与 Web 应用程序接口代码分离。

本质上,整个系统由三个主要组件组成:

  • GUI(Catalyst Web 界面)
  • 爬虫
  • 一个“攻击组件”(编写该应用程序是为了查找其他 Web 应用程序/站点中的 XSS 和 SQLi 漏洞)

因此,理论上 GUI 会为以下人员创造就业机会:爬虫反过来为“攻击组件”创造就业机会。

目前,我在 Catalyst 中有一个模型,它实例化了 TheSchwartz 对象,以便 Web 应用程序中的控制器可以将作业添加到作业队列中。

我还需要创建一些作业工作者脚本来连续侦听(/检查数据库)新作业,以便它们可以执行所需的操作。目前 TheSchwartz 的数据库特定内容位于 Catalyst 的模型中,我认为我无法在 Catalyst 之外轻松访问它?

我不想在模型中复制 TheSchwartz 作业队列的数据库连接数据,然后在我的作业工作者脚本中复制。我是否应该将 TheSchwartz 对象的创建包装在 Catalyst 外部的另一个类中,并在当前实例化 TheSchwartz 对象的模型中调用它?然后我也可以在工作脚本中使用它。或者我应该将数据库数据放在配置文件中,并在需要时实例化新的 TheSchwartz 对象(在 Catalyst/内部作业工作者脚本内)?

还是我只是想多了?

一些指向丰富的 Web 应用程序架构文章的链接也可能有用(我以前从未构建过中等复杂度的文章..)。

干杯

I'm writing a web application using the Catalyst framework. I'm also using a Job Queue called TheSchwartz.

I'm wanting to use a job queue because I'm wanting as much of the application specific code decoupled from the web application interface code.

Essentially the whole system consists of three main components:

  • GUI (Catalyst web interface)
  • A crawler
  • An "attacking component" (the app is being written to look for XSS and SQLi vulnerabilities in other webapps/sites)

So in theory the GUI creates jobs for the crawler which in turn creates jobs for the "attacking component".

Currently I have a Model in Catalyst which instantiates a TheSchwartz object so that Controllers in the web app can add jobs to the job queue.

I also need to create some job worker scripts that continuously listen (/check the database) for new jobs so they can perform the required actions. Currently the DB specific stuff for TheSchwartz is in the Model in Catalyst and I don't think I can easily access that outside of Catalyst?

I don't want to duplicate the DB connection data for TheSchwartz job queue in the Model and then in my job worker scripts. Should I wrap the creation of TheSchwartz object in another class sitting outside of Catalyst and call that in the Model that is currently instantiating TheSchwartz object? Then I could also use that in the worker scripts. Or should I have the DB data in a config file and instantiate new TheSchwartz objects as and when I need them (inside Catalyst/inside job worker scripts)?

Or am I just over thinking this?

Some links to meaty web app architecture articles may also be useful (I've never built one of moderate complexity before..).

Cheers

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

时光与爱终年不遇 2024-08-16 01:58:00

您使用 DBIx::Class 吗?即使您不是,这里的基本思想也适用,但我将继续假设您是。

Catalyst 模型应该是另一个类的包装器,只提供足够的行为来与 Catalyst 交互,而不是其他。例如 Catalyst::Model::DBIC::Schema 只是 DBIx::Class::Schema 的包装。它从 Catalyst 获取配置并将其传递给 DBIC,它将 ResultSet 注入到 Model 命名空间中(以便您可以执行 $c->model('DB::Table') 技巧) ,然后它就消失了。

优点是,由于所有重要代码都位于 Catalyst::Model 之外,因此它完全独立于 Catalyst。您可以从维护脚本或作业队列工作人员或其他任何方式加载您的架构,向其传递一些配置,告诉它连接并运行,而无需调用 Catalyst。 ResultSet 中的所有信息和逻辑以及其他内容在 Catalyst 外部和内部同样可用。

Are you using DBIx::Class? The basic idea here applies even if you're not, but I'm going to go ahead and assume that you are.

A Catalyst model should be a wrapper for another class, providing just enough behavior to interface with Catalyst, and nothing else. For example Catalyst::Model::DBIC::Schema is just a wrapper for DBIx::Class::Schema. It gets the config from Catalyst and passes it to DBIC, it injects the ResultSets into the Model namespace (so that you can do the $c->model('DB::Table') trick), and then it gets out of the way.

The advantage is that since all of the important code lives outside of Catalyst::Model, it's completely independent of Catalyst. You can load up your Schema from a maintenance script or a jobqueue worker or whatever else, pass it some config, tell it to connect and go, without ever invoking Catalyst. All of the information and logic that's in your ResultSets and whatever else is equally available outside of Catalyst as inside.

我早已燃尽 2024-08-16 01:58:00

如果我理解正确,您的问题是“如何在 Catalyst 之外重用我的数据库连接?”。

您应该在 Catalyst 应用程序中使用 DBIx::Class。您可以在任何其他应用程序中重复使用相同的文件。 Catalyst 中的 $c->mode('DB::MyTable')->search(...) 与 Catalyst 外部的相同:

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

任何模型都可以在 Catalyst 外部调用,例如常规包 MyApp::Model::Library->new()。您只是想确保不使用 $c 作为参数。

If I understand correct, your question is "how can reuse my database connection outside of Catalyst?".

You should have used DBIx::Class within your Catalyst application. You can reuse the same files in any other application. $c->mode('DB::MyTable')->search(...) in Catalyst is the same as this outside of catalyst:

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

Any Model can be called outside of Catalyst like a regular package MyApp::Model::Library->new(). You just want to make sure you do not use $c as an argument.

忘你却要生生世世 2024-08-16 01:58:00

您应该注意的一件事是使用 TheSchwartz::Simple 创建就业机会而不是 TheSchwartz 本身(您实际上只需要它来处理就业机会)。优点是:

  • 轻量级(无需将整个 TheSchwartz 加载到 Catalyst 应用程序中)
  • 接受简单的数据库句柄来连接到数据库,而 TheSchwartz 本质上有自己的数据库包装层,并且需要您为其提供用户名和密码,管理它自己的连接(你说过你不希望它这样做)

One of the things you should take a look at is using TheSchwartz::Simple to create jobs rather than TheSchwartz itself (which you really only need in order to process jobs). The advantages are:

  • Lightweight (no need to load the entire of TheSchwartz into your Catalyst App)
  • Accepts a simple database handle to connect to the database, whereas TheSchwartz essentially has it's own database wrapper layer and will want you to give it usernames and passwords and manage its own connection (which you've said you don't want it to do)
~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文