网站管理后台适合前后端分离，做成 SPA 吗？

[rv54ntjwfm3ug8]

感觉挺适合的，后台完全不需要 SEO ，超旧版本浏览器兼容性也不是非常重要 就是感觉如果不搞个前置 basic_auth 的话未登录 /低权限账号也可以看到 main.xxx.js 导致全部接口信息泄露 一般是怎么处理？

[ragnaroks]

接口本来就是公开的，做好鉴权就行

与其做成 SPA 不如考虑下 SSG ，举个例子某管理员 A 可以复制某个特定功能的链接直接发给管理员 B

[Hanggi]

后端网站限制访问，限制 IP

[Chism]

容易被反推有哪些页面，甚至页面的某些内容。
纯后端渲染，没权限就无法提前看到路由和网页结构

[pengtdyd]

啊！！！！你是不是搞 IT 的哦，前后端分离 5 年前就大行其道了好吧。

[815979670]

这个情况看，项目大不大，团队的构成，采用的语言等等。
如果：项目不大，就一两个人后端开发维护，用的还是 PHP 语言，那自然是 MVC 更方便。
如果：项目不大，但有一个前端，有一个后端 那前后端分离，我写我的接口，你写你的页面 每个人都能专注自己的部分
如果：项目很大，N 个前端，N 个后端，那么前后端分离，通过共享来传递接口文档，各司其职 后期重构也可以单独重构前端或者单独重构后端。

[BaiLinfeng]

啥意思啊，直接看不懂

[wunonglin]

接口信息泄露？网站接口都是控制台直接看到，你指的泄露是什么意思？

[murmur]

后端不搞鉴权是在开玩笑么，企业应用做假鉴权是因为大家都是抬头不见低头见，互联网应用敢不做数据权限的？

[gouflv]

感觉回到 10 年前

[GeruzoniAnsasu]

1. 接口信息是不应该怕泄露的，有很多业务甚至为了方便自动化会主动把接口暴露并提供规范的使用方法
2. 鉴权和 csrf token 之类的东西早都已经纳入各种框架中了，都可以拿起来就用，不用担心实现难度
3. 前端的 distribution 版 js 都是压缩混淆过的东西，一般人可看不懂，甚至就算不压缩混淆，框架的源码复杂度已经足以令人发指了

[ccyu220]

看标题我以为现在是 2012 年

[sjzjams]

进来我就看成做 SPA 。。

[superfatboy]

看标题我以为现在是 2011 年

[focuxin]

前端做路由守卫，后端做好接口鉴权，js 本来就是透明的，再说现在前端工程的复杂性，代码都是压缩的，看接口请求开发者工具直接就能看到。

[joesonw]

可以 spa 都管理节目前面放一个表单登陆，登陆了才去到有 js 的页面。而且一般公司不都走统一登陆了吗，一样的效果。

[wowbaby]

我之前后台都用单应用模式，路由鉴权很是麻烦，后换成 MVC 再引入 Vue ，个人觉得方便多了，两者的优势都发挥了

[ijse]

当你考虑构建的软件应该是什么样子时，你需要先考虑一下你的组织架构应该是什么样子。它们总是相辅相生的。

[encro]

@ragnaroks

别吓人，
管理后台做 SSG ，难道要为每一条内容生成一个页面？
直接 SPA 也是支持路由和复制的。

一般只有前台才需要 SSR 和 SSG 。

[Envov]

main.xxx.js 可以做成 lazy load ，访问特定路由才加载特定的 chunkjs

[ragnaroks]

@encro 你对 SSG 的理解有误

[libook]

接口不泄露也要做好鉴权，鉴权做好了泄露也无所谓。

[encro]

@ragnaroks

你说的 SSG 不是服务端生成？

[ragnaroks]

@encro 是服务端生成，SSG 尤其适合纯静态前端与数据后端合作，并不存在所谓每一条内容生成一个页面，而是每个路由在没有后端支持的情况下仍然可达，即使是文章很多的类 CMS 项目也不存在一个文章生成一个页面，PWA 就是带 SW 的 SSG ；假设你理解 SSG 那么我姑且认为你只了解过其使用方式但从没实际生产过；如果你认为我说的不对，你完全可以以你自己的理解为准，不用回复我

[encro]

@ragnaroks

真没找到后台采用 SSG 的案例，非常希望赐教。

[encro]

@ragnaroks

我只知道一些 Blog 或者 CMS 前端采用 SSG ，主要解决性能、安全和 SEO 问题。

按你回复我都搞不清楚 SSR 和 SSG 的英文意义和区别了。

[ragnaroks]

@encro
阿里云用户后台和腾讯云用户后台都是 SSG

假设有一个路由 /user/signin-history/[dateRange]

SPA: 直接访问为 notfound ，需要 nginx 之类提供 404 回落

SSG: 可直接访问，页面展示部分不可变数据，最新数据需要额外 HTTP 请求

SSR: 可直接访问，页面已展示对应最新数据

适用于楼主的场景，假设这里是一个用户管理系统，管理员 A 打开某个用户的详情页 /user-magane/user-list/[uid]/detail/，这个用户行为异常需要移交技术核查，则可以直接将这个地址发给技术人员，技术打开页面直接做后续处理

事实上 SPA 、SSG 、SSR 是一类技术，SSG 就是有路由支持的 SPA ，SSR 就是不需要客户端 js 支持的 SSG ； SSR 太重而 SPA 太慢（需要加载所有 chunk ）

与早期技术对比，比如 dz 、phpcms ，最接近的是 SSR 而不是 SSG

你在第 25 楼的第一行观点完全准确，但后台管理用 SSG 主要是后台管理往往模块很多，利用 SSG 做 chunk 拆分可实现增量更新，而且加载速度快，而 SPA 只适合工具类网站比如在线计算器

可能是一些静态网站生产工具都是面向内容产生设计，最终产出 *.html 导致你对 SSG 有一些错误了解

[ragnaroks]

补充一个，使用 nodejs 承载的不一定就是 SSR ，也可能是 SSG ，但 SSG 不需要 nodejs 承载

[encro]

@ragnaroks

抱歉你可能还是无法说服我吧。

客户端渲染 BSR (Broswer Side Render)
静态站点生成 SSG (Static Site Generation)
服务端渲染 SSR (Server Side Render)

我的理解 SSG 就是静态页面生成。
我用过的 nuxt,Next,vite 官方文档里面 SSG 也是静态站点生成这个意义。
至于 dz 、phpcms 这种我叫他 AJAX ，因为他就没有 nodejs 什么事。

我看到阿里云文档这种，可能属于是 ssr 也可能属于 ssg ，这个不属于管理后台。
至于说控制台，我认为他就属于 ajax 或者 SPA ，没有 SSR 和 ssg 什么事。

我认为管理后台，还是用 spa 或者 ajax 方式好，用 SSR 和和 SSG 属于没有事情干了？

[panxiuqing]

@ragnaroks
是你没理解前端路由，不管 SPA 路由使用 hash 还是 history 模式，在你举例的发送链接场景中都不存在问题。

[ragnaroks]

@panxiuqing 你说了一句正确的废话，上面一句说过了 SSG 不需要 404 回落和现代浏览器支持。

[panxiuqing]

@ragnaroks
想知道 是 hash 需要现代浏览器 还是 Nginx 配置这个实现成本低到无法想象的东西拿出来说不是正确的废话

[panxiuqing]

@ragnaroks
或者说将 Web 服务器配置成按原始文件目录映射 URL Path 有特殊的地位？

[ragnaroks]

@panxiuqing 一个你可能这辈子没机会接触的社保后台，原来是使用 dedecms 搭建的，后由于总是被通报而且更新难度较高，于是移除所有 view 后以接口的形式应用新的前端； react 17 需要兼容到 IE 8 即 win7 ，而且前端站点所在的机器我作为乙方没有权限，只能打包后让对面的运维手动放置到其使用 iis 6 创建的站点中； hash 是可以用的，但后台数据（某个公民的信息）在需要的情况下会被通过链接的形式发送给其它部门，hash 路由被甲方否决了，理由是看起来不安全；但凡你和单位打过交道也不会想当然用 nginx ，甚至还想进对面服务器？

[panxiuqing]

@ragnaroks
首先是你说 Nginx 我才提 Nginx ；其次希望以后不要把甲方要求作为开放观点的论据。

[ragnaroks]

@panxiuqing 26 楼说的很清楚，SPA 需要 404 回落，这是缺陷，怎么到你这就变成了“首先是你说 Nginx 我才提 Nginx ”，还“不要把甲方要求作为开放观点的论据”，你即世界是吧

[panxiuqing]

@ragnaroks

首先得清楚讨论的点是什么，不然才是“你即世界”。

看一下自己的论证链：
“与其做成 SSG ，不如考虑下 Hash 路由吧，举个例子某管理员 A 可以复制某个特定功能的链接直接发给管理员 B”
“这个需求用 SSG 也完全没问题”
“用 SSG 还要考虑用 Next 之类的框架”
“用 Next 这个框架也不麻烦”
“因为我遇到过某个甲方要求用 Hash 路由，而且他们根本不用 Next ，不要想当然以为可以用 Next”

希望你能明白问题到底在哪里。

[ragnaroks]

主要论点就是“与其做成 SPA 不如考虑下 SSG”。

SSG 具有 SPA 全部功能的同时还有更多的优势，为什么要使用 SPA ？

“举个例子某管理员 A 可以复制某个特定功能的链接直接发给管理员 B”、SSG 不需要 404 回落、大厂使用 SSG 而不是 SPA 、SSG 可以增量加载。

你这论证链看起来为了圆一个不得不扯出更多。

[ragnaroks]

@encro
现在才看到你的回复，这个我没有打算说服你，因为请求建议的是楼主。

你单说的“我的理解 SSG 就是静态页面生成”是完全没问题的，但是静态页面生成的方式有很多，除了现在常见的打包，在你举例的 dz 、phpcms 本身就有将路由生成为 html 页面的功能，只不过那时候叫“缓存”； ajax 和 SPA 、SSG 之类没啥关系；但是控制台确实是 SSG 的，因为 SSG 可以被提前预热分发，用户最终只需要通过 ajax 获取一次他自己的数据即可；虽然 SPA 做后台也是可以的，但是就如上面所说，SSG 比起 SPA 有更多优势，比如基于页面分块、增量更新，试想一个后台可能几百个页面，如果打包成 SPA 那么等于整个站点文件全部都需要更新，但是 SSG 只需要更新几个 js

[encro]

@ragnaroks

还是没搞清楚你对 SSR 和 SSG 的定义。

另外：SSR,SSG,SPA 都是可以复制链接发送给其他人的。

[ragnaroks]

@encro

26 楼。

另外：水桶、水杯、水管 都是可以喝水的。

[encro]

静态站点生成 SSG (Static Site Generation)
服务端渲染 SSR (Server Side Render)

注意这两个 SS 是不同的意思一个是 Static Site,一个是 Server Side 。