2
网站管理后台适合前后端分离，做成 SPA 吗？
source link: https://www.v2ex.com/t/844419
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.
感觉挺适合的，后台完全不需要 SEO ，超旧版本浏览器兼容性也不是非常重要
就是感觉如果不搞个前置 basic_auth 的话未登录 /低权限账号也可以看到 main.xxx.js 导致全部接口信息泄露
一般是怎么处理？
28 条回复 • 2022-04-02 22:01:05 +08:00
815979670 1 天前 
1
这个情况看，项目大不大，团队的构成，采用的语言等等。
如果：项目不大，就一两个人后端开发维护，用的还是 PHP 语言，那自然是 MVC 更方便。
如果：项目不大，但有一个前端，有一个后端 那前后端分离，我写我的接口，你写你的页面 每个人都能专注自己的部分
如果：项目很大，N 个前端，N 个后端，那么前后端分离，通过共享来传递接口文档，各司其职 后期重构也可以单独重构前端或者单独重构后端。
如果：项目不大，就一两个人后端开发维护，用的还是 PHP 语言，那自然是 MVC 更方便。
如果：项目不大，但有一个前端，有一个后端 那前后端分离，我写我的接口，你写你的页面 每个人都能专注自己的部分
如果：项目很大，N 个前端，N 个后端，那么前后端分离，通过共享来传递接口文档，各司其职 后期重构也可以单独重构前端或者单独重构后端。
GeruzoniAnsasu 16 小时 46 分钟前
1. 接口信息是不应该怕泄露的，有很多业务甚至为了方便自动化会主动把接口暴露并提供规范的使用方法
2. 鉴权和 csrf token 之类的东西早都已经纳入各种框架中了，都可以拿起来就用，不用担心实现难度
3. 前端的 distribution 版 js 都是压缩混淆过的东西，一般人可看不懂，甚至就算不压缩混淆，框架的源码复杂度已经足以令人发指了
2. 鉴权和 csrf token 之类的东西早都已经纳入各种框架中了，都可以拿起来就用，不用担心实现难度
3. 前端的 distribution 版 js 都是压缩混淆过的东西，一般人可看不懂，甚至就算不压缩混淆，框架的源码复杂度已经足以令人发指了
encro 15 小时 35 分钟前
ragnaroks 12 小时 11 分钟前
@encro 是服务端生成，SSG 尤其适合纯静态前端与数据后端合作，并不存在所谓每一条内容生成一个页面，而是每个路由在没有后端支持的情况下仍然可达，即使是文章很多的类 CMS 项目也不存在一个文章生成一个页面，PWA 就是带 SW 的 SSG ；假设你理解 SSG 那么我姑且认为你只了解过其使用方式但从没实际生产过；如果你认为我说的不对，你完全可以以你自己的理解为准，不用回复我
encro 11 小时 28 分钟前
ragnaroks 10 小时 16 分钟前 1
@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 有一些错误了解
阿里云用户后台和腾讯云用户后台都是 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 有一些错误了解
encro 3 小时 20 分钟前
@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 属于没有事情干了？
抱歉你可能还是无法说服我吧。
客户端渲染 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 属于没有事情干了？
Recommend
About Joyk
Aggregate valuable and interesting links.
Joyk means Joy of geeK