拥有单独的 Web 应用程序的标准是什么?
我正在尝试设置一个 Rails 项目,该项目有 2 个逻辑上独立的组件:管理面板和用户门户。根据我到目前为止所读到的内容,有多种方法可以进行设置;
- 将两者合并在一个具有单个数据库的 Web 应用程序中
- 管理和主应用程序的单独 Web 应用程序,但使用通用数据库
- 具有单独数据库的单独 Web 应用程序
- 合并两者,但部署单独的实例,一个作为管理员运行,另一个作为主应用程序运行
主应用程序需要处理大量流量,管理权限较低。
在这四个选项中,建立项目的最佳方法是什么?
还有各自的缺点是什么?
有没有其他方法可以做得更好?
I'm trying to setup a Rails project that has 2 logically separated components, the admin panel and the user portal. From what I've read so far there are a number of ways to set this up;
- Combine both in a single web app with a single database
- Separate web apps for Admin and Main apps, but use a common database
- Separate web apps with separate databases
- Combine both but deploy separate instances, one running as Admin and other as Main app
The Main app will need to handle heavy traffic, the admin moderately low.
What is the best approach to set up the project among the four options?
Also what could be the downsides of each?
Is there any other way this can be done better?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
关于可能的架构解决方案的一些想法:
1. 将两者与单个数据库结合在一个 Web 应用程序中
优点:
您可以在单个项目配置下拥有所有内容,
这样您就可以避免两次配置项目设置。
您可以重复使用代码,而无需复制文件或参考文件
在不同的目录中,这有时会很麻烦。
缺点:
与用户相关代码在同一屋檐下,所以存在的概率较大
恶意用户可以利用与管理相关的功能。
2. 将管理应用程序和主应用程序分开,但使用通用数据库
优点:
并且两者的用户体验都更加简洁。
缺点:
主应用程序,它必须读取并影响主应用程序中使用的数据;因此可以减少开销。
在大多数情况下,这将是最好的情况。
3.使用单独的数据库来分离网络应用程序
当第二个应用程序意味着时,无法想象为什么要这样做
处理第一个和数据库的内容。
如果你打算
在第二个应用程序中使用与您无关的大量数据
主要应用程序,这将是一个合理的选择。
4. 合并这两个实例,但部署单独的实例,一个作为管理员运行,另一个作为主应用程序
缺点:
您将开发解决方案一,同时处理两个实例会增加复杂性。
恶意用户可能会找到一种方法来登录您的管理实例并访问
管理级功能。
Some ideas about the possible architectural solutions:
1. Combine both in a single web app with a single database
pros:
You have everything under a single project configuration,
and by so you avoid to configure your project settings twice.
You can re-use code without needing to copy files or reference files
in a different directory which sometimes can be troublesome.
cons:
under the same roof with the user-related code, so it there is a bigger probability
that admin-related functions can be exploited by a malicious user.
2. Separate web apps for Admin and Main apps, but use a common database
pros:
and the user experience in both of them more concise.
cons:
the main application, it will have to read and affect the data used in the main application; hence giving you less overhead.
This would be the best case in most scenarios.
3. Separate web apps with separate databases
Can't think why you want to do this when the second application is meant
to handle the first one and the contents of the database.
If you were going to
use a big volume of data in the second application that were irrelevant to your
main application, it would be a reasonable option.
4. Combine both but deploy separate instances, one running as Admin and other as Main app
cons:
You will develop solution one with the added complexity of handling two instances.
A malicious user might find a way to login in your admin instance and getting access to
admin-level functions.