关于前后端分离的一些疑问

[yezheyu]

以前没写过前后端分离的项目，想请教下架构怎么设计

例如未分离时，像登录成功后的页面跳转到首页的功能

是在后端校验完，后端重定向到首页接口，再由首页接口返回首页的 html 页面

页面的跳转是由后端负责的

那如果项目改成前后端分离，页面的重定向是由前端负责吗？

前端页面使用 ajax 向后端发送请求

后端校验后，不进行重定向，只返回状态码和 json 数据

前端根据状态码决定是在当前页面提示登录错误信息，还是登录成功跳转到首页

是这样设计吗？前后端分离后所有的页面的跳转都是由前端负责，后端只负责返回数据

[molvqingtai]

理解正确

[shabbyin]

重定向谁做都可以
后端做的话 可以直接返回 301 302
前端做的话就加拦截器 发现接口返回对应的响应码 就重定向到登录页

[zhuweiyou]

重定向肯定是客户端负责. 你想象一下你的 API 如果给 APP 用,你能控制 APP 的跳转吗?

[ChefIsAwesome]

楼上说的没错。你就想着是写原生 app 的后端，自然就没有以前的包袱了。

[yezheyu]

@molvqingtai

那以前前后端未分离时，对于密码等参数的校验，前端需要校验一次，后端也要校验一次

改成前后端分离后，是不是前端可以不用再校验，只用后端校验一次就可以

[fiypig]

@yezheyu 一样要做校验

[dcsuibian]

以前是后端直接给 html 页面的，差不多是这样，他来告诉你跳到哪儿，所以叫后端路由。去到不同的页面就是给你不同的 html 页面，所以就是多页的。

现在前端应该多是单页应用，前端根据拿来的数据决定跳到哪儿。后端只负责提供数据。
说是跳转，实际上就是网页内容的替换，配合浏览器的 history api 变更地址栏，看起来就像跳到了新页面。所以叫前端路由。
一个明显的地方就是浏览器的刷新按钮根本没动过，因为就是原来那一个页面，所以叫单页应用。

[Erroad]

@yezheyu #5 前端校验是为了验证参数本身格式是否有问题，并且给用户提示；后端是登录鉴权等登录逻辑，也可能有格式校验。要从功能本身出发啊

[lyusantu]

@yezheyu
前端效验是减轻服务器压力，如果不效验并且参数不符合要求的话，会导致频率请求接口，白白浪费资源

不过无论前端效验不效验，后端都是要效验的，毕竟

[yezheyu]

@fiypig
为啥呢？

以前是：
前端：校验数据 ——> 后端：校验数据

前端提前校验数据是为了让用户知道输入错误
后端校验是保证存到数据库的数据的正确性

</br>

现在是：
前端 ——> 后端：校验数据 ——> 前端：取出参数错误信息加载到页面上

前段不加校验的话，不是可以从后端返回的参数错误信息取数据加载到页面上吗？
一样可以提醒用户输入错误

为啥还要校验呢？

[yezheyu]

@lyusantu

是为了减轻后端接口的压力，减少接口请求的次数

明白了，多谢老哥

[fiypig]

@yezheyu 前端校验减轻服务器压力, 后端校验防止有些是通过工具请求的

[yezheyu]

还有个问题想请教下各位老哥


以前 html 页面由后端服务器直接生成，返回给浏览器

现在改成前后端分离了，html 页面是由谁返回给浏览器呢？是前端自己有个单独的服务器吗？

如 nginx ？前端页面开发好后直接把所有的 html 页面当做静态资源交给 nginx 管理是吗？

后端的接口再单独部署一台服务器，再交给 nginx 反向代理


</br>


所以对于一个 url ，如果是请求 html 页面，则直接由 nginx 路由处理

如果是个接口，则由 nginx 转发给后端服务器


是这样吗 ?

[yezheyu]

@dcsuibian

[yyfearth]

@yezheyu @fiypig 不仅仅是减少压力 而且也改进用户体验呀
你想想 如果全部都给后端校验 一来一回怎么样也要半秒钟以上吧
前端校验可以做到边输入边校验

更高级的 前端可以预处理数据 进一步减轻后端的压力 或者增大爆破的难度

后端校验 因为你不能相信前端 用户或者黑客可以劫持网络 或者 打开浏览器 console 直接请求服务器 跳你的前端代码
而且前端不仅数据没办法保证 连代码都没办法完全保证 可以通过劫持网络 注入 或者 浏览器扩展 轻松提起修改数据 和篡改代码

[yyfearth]

@yezheyu html 页面 现在都是推荐直接使用 CDN
CDN 后面连一个云存储 比如 S3 之类的

如果非要用自己的服务器 直接一个静态服务器就可以了

如果要用 cookie 那需要 CDN 或者负载均衡可以转发后端 用 nginx 的话 就和你说的一样
如果用 jwt 的话 可以前后端服务器都分离 用不同的域名
做好服务器的 CORS 跨域认证就没问题了

[yyfearth]

@yezheyu 现在 除非是内部服务 或者使用者非常小的服务 否则都不推荐直接服务器 连虚拟机都不是很推荐了
有能力直接上 K8n 或者 Docker

[yyfearth]

k8s 或者 docker
就算是内部服务 用 docker 部署起来也方便不少

[dcsuibian]

@yezheyu
单页应用的话，可以参考 vue router 的说明：
https://router.vuejs.org/zh/guide/essentials/history-mode.html#%E6%9C%8D%E5%8A%A1%E5%99%A8%E9%85%8D%E7%BD%AE%E7%A4%BA%E4%BE%8B

拿 Spring Boot 举例，直接 build 到后端 src/main/resources/static 里然后和后台程序一起打成 jar 包就可以直接跑了
但其实更多的应该是 Nginx ，好扩展，而且前后端分离的比较彻底，比较推荐

原理上就跟你想的一样，把请求 api 的和请求页面的分开处理。api 的话，主要有两种，api.xxx.com 或 xxx.com/api 这样的。
单页应用应该只有一个 index.html 。注意如果客户端直接访问一个地址 xxx.com/user-center/advance ，也要把 index.html 返回去，xxx.com/user-center/advance 这个链接到底有没有还得前端 js 执行了再说，没有就跳到前端做的 404 页面。

[libook]

跟用户交互有关的尽可能都放在前端，后端只为前端提供数据、核心业务功能、安全性。

同为前后端分离，不同需求用不同重定向方式；如果是 HTTP 协议层的原因需要重定向，如为转移位置的资源进行重定向，或由 HTTP 协议升级成 HTTPS 协议的重定向，可以由后端来完成；虽然是后端完成，但用户不一定会有感知，比如一个页面请求的一张图片从一个 URL 移动到另一个 URL 了，后端返回了重定向，然后浏览器去新 URL 获取资源了，这个过程用户可能只看到了一张图片加载出来，并没有感知到中间经过了一次重定向；跟用户交互有关的页面跳转，可以使用前端重定向，比如可以在前端登录页面判断服务器返回的登录结果信息，成功就跳转到功能页面。