死磕架构之——前后端到底怎么分？（一段代码逻辑到底该放在前端还是后台？）

        在当前软件开发过程中，前后端分离、并行、协作的开发模式下，在js各种框架秒天秒地的存在，有的前端不止做了页面展示，也含有部分业务逻辑。我的问题是前端做的事有哪些？前端可不可以含有部分业务逻辑？哪些可以在前端做？哪些不能放在前端？ 我先说说我自己碰到的情况和自己的想法？
故事一:
前几天我接触一个项目，我做后台，另一同事做前端。他在前端给我一系列参数，我在数据库取出数据返回一个Json给他，突然碰到一个数据统计的业务，他说要不后来计算一下再传给我？我持反对态度，一是这数据计算一个倒还好，要是计算复杂并且很多人访问的时候，明显增加了服务器压力，而且传输过程中会增加数据量，我觉得不好，能让前端处理的事别放到后端最好！
故事二:
我本科信息安全专业的，所以工作中偶有会关注一下架构的安全情况。我之前看到有个同事对于某些数据访问的权限放到了前端。（就是javascript通过状态去控制某些访问），我碰到架构师，闲聊了一下，我觉得这是很糟糕的情况。他说这个项目很多控制就是这样的，在前端控制的，反正用户又不是学计算机的，我瞬间无语，当然这架构是之前的架构师搞的。
说说我的看法:
1.在前后端分离趋势下，页面的展示全部交有前端处理（所以我不推荐使用jsp等需要在服务器做过多事情的东西）；
2.前端要尽量减少后台的压力，把计算的压力放到前端。当然这些代码不会暴露你不想暴露给别人看到的业务规则，例如某个不想别人知道的算法（绝大部分情况是没有的，我觉得） ；
3.如果我们给业务逻辑严格定义，那么前端也不应该有业务代码，我所说的业务代码是指会影响业务流程的代码。（可能我碰到的情况少，也有可能部分非关键业务代码可以放在前端，只不过我没碰到）
4.不该前端含有的，包括各种验证，认证，安全控制，权限控制，数据访问控制都应该在后台处理，不给用户的东西，就千万别传往前端，即使在前端再做控制这也不行；
5.关于用户体验的问题，如果前端做的事太多了，首先优化前端，如果还不够好再考虑往后端挪必要的一部分。

总结： 在用户体验能接受的情况下，给后台做必要且最少的事，在某些Web应用中，可以把前端做一个主战场。也许这与很多公司的做法不一样（给后台的资源远远大过前端）。

阅读更多