boot+angular项目结构与架构

r1zhe5dt  于 2021-07-13  发布在  Java
关注(0)|答案(1)|浏览(373)

关闭。这个问题是基于意见的。它目前不接受答案。
**想改进这个问题吗?**更新这个问题,这样就可以通过编辑这篇文章用事实和引文来回答。

上个月关门了。
改进这个问题
我正在构建一个应用程序,它由一个spring引导后端和一个Angular 前端组成。以下项目结构有哪些优点和缺点?
要求:
maven项目
spring security(登录+注册)->表单?基本的?jwt公司?
角形前端
spring引导后端
我想到了以下可能性:

在同一服务器上运行的spring项目

angular项目文件夹在spring boot项目中。在构建springboot应用程序时,Angular 项目被构建并包含在静态文件夹中。
优势:
只有一个可部署的
Spring Security 的简单使用(表单登录+会话)
单一代码基
缺点:
用户界面高度依赖于后端
负载平衡可能更困难(我对此不确定)

spring-boot+angular在一个项目和同一个服务器中

angular应用程序和SpringBoot应用程序位于不同的文件夹中(可能是一个根项目,包括这两个maven模块)。在构建spring项目时,Angular 项目将被构建并包含在其目标文件夹中(类似于:https://github.com/fraktondevelopers/spring-boot-angular-maven-build)
优势:
只有一个可部署的
Spring Security 的简单使用(表单登录+会话)
单一代码基
多模块maven项目
缺点:
用户界面高度依赖于后端
负载平衡可能更困难(我对此不确定)

在一个项目和不同的服务器上使用spring boot+angular

angular项目文件夹与spring启动项目位于同一个项目中(可能只有一个根文件夹,其中ui和后端项目作为单独的文件夹)。后端和ui在不同的服务器上运行(angular不包括在jar/warofspring引导中)
优势:
单一代码基
从后端分离ui的缺点:
安全性要困难得多(您需要检查用户是否在前端手动登录并手动接收session/jwt)

spring-boot+angular在不同的项目和不同的服务器上运行

这两个项目是完全分开的(两个git回购),没有共同的代码。它们部署在不同的服务器上。
优势:
从后端分离ui的缺点:
安全性要困难得多(您需要检查用户是否在前端手动登录并手动接收session/jwt)
开发时必须打开两个项目
哪个项目结构是“最佳实践”?还有其他选择吗?我错过了什么优点/缺点吗?
是否有任何示例项目/开源项目?我更喜欢生产就绪的架构/结构,最好包括Spring Security 。

yebdmbv4

yebdmbv41#

安全
“springsecurity的易用性”可能没有您想象的那么容易。特别是,“表单登录和会话”部分不会在开箱即用的情况下工作:
当客户端发送一个没有有效(或过期)凭据的请求时,Spring Security 将截获该请求,并使用登录表单进行响应。如果请求是浏览器中的一个页面导航,那就很好了,但是如果无效的请求命中了api端点呢?发出xmlhttprequest的angular服务不知道如何处理这个意外的html文档。
还有,会话?例如,我发现从可用性的Angular 来看,会话过期是非常烦人的,通过angular,应用程序状态可以很容易地保存在浏览器中,从而使我们能够摆脱服务器端会话(这也很好地防止了csrf攻击,否则您的api可能会受到攻击,简化了负载平衡,并提高了后端的可扩展性)。
因此,虽然springsecurity可以帮助进行访问控制,但它不能解决登录部分,因此不能从同一服务器提供ui服务中获益。
其他考虑因素
值得注意的是,开发和运行期间的“聚合性”可以独立决定。
对于发展,我会考虑:
我是否可以在不同的前端使用后端?
是同一个人做前端和后端的更改,还是由不同的人做这些更改,可能是在不同的时间?这些变化是一起发布还是分开发布?
我的测试策略是什么?前端和后端是单独测试还是一起测试?
因此,如果我有一批全栈开发人员,他们每个人都将在所有层上实现他们的功能,一起发布和测试,所有内容都将进入同一个存储库并进行构建(尽管我仍然保留在开发过程中单独构建前端的能力:当我更改代码时,无需等待spring引导重新启动)。
相反,如果我有一个独立的前端和后端团队,他们的版本可能会不同步,他们会单独测试,我会创建单独的存储库和构建。
对于运行时,我会考虑:
易于部署:在我希望部署到的任何地方一起部署还是单独部署更容易?
这几乎是唯一的考虑。尤其是,在httpapi之外不应该有任何耦合,因为这种耦合不会带来任何好处,也不会抑制系统的未来发展:如果ops首选项或最佳实践发生变化,我希望能够对此做出响应。例如,如果我以后想在ui中使用cdn,我应该可以很容易地做到这一点。

相关问题