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

[rv54ntjwfm3ug8]

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

[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 楼。

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