为什么前端老觉得后端简单？
RT。
这里的前端包括(h5 android ios)
当一个app推向市场时，
第一个阶段
用户比较少，前端后端的压力一样大。此时的重点在于把功能实现
伺服器可能只有1台 (单机架构)
第二个阶段
公司开始通过一些渠道推广app，
运营人员通过一些活动开始拉新，
每一天的注册量都上万，
日活慢慢的开始飙升，伺服器压力变大，测试反馈说，app好像微微的有点卡。
考虑到后续的流量发展，后端老大，加了4伺服器(假设配置都一样)，现在一共有5台
第三个阶段
运营持续发力，产品功能继续迭代，
新用户越来越多，老用户持续活跃，
日活慢慢靠近5万
某天深夜，app挂了，打开任何一个页面都空白一片，500 504频繁出现。
监控系统，不停报警，老板震怒，电话把技术部老大骂一顿，催促赶紧解决，
技术部老大，把核心后端叫醒，讨论解决方案，
最快的解决方案是，先加机器，扛过今晚再说。
前端睡的很香，第二天醒来听说app昨晚挂了
开始分析日志和监控系统，昨晚流量高峰时，
发现mysql连接数耗尽，单机的扛不住，在调整了一些系统参数和mysql参数后，压测，发现还是扛不住，升级资料库架构，单机器升级为一主一从，把读写进行分离。
为了保证mysql的稳定性，又加了一个连接池。
第四个阶段，
五十万日活
cdn，
缓存系统，
集群架构升级当分散式架构
分散式再升级到微服务架构
用户看不见的系统越搞越多，
比如
日志系统
请求链路追踪
队列任务中心
网关系统
配置中心
等等，
中间件越用越多，
数据量越来越大，
慢慢的有了大数据岗位。
说的不够细致，总的来说，
当流量越来越大时，前端可优化的地方并不多。
介面还是那个介面，单日活1万，和日活50万
后端系统的复杂度，不可同日而语。
事实很内卷，faas/baas 是趋势，后端必然要往集群化，集中化，资源化发展，后端不去研究devops，微服务，呆在中间件赖著不走，被喷也正常。
前端吐槽后端简单，大概率是想把后端从中间件赶走，受不了奇葩的数据格式和联调时的加班了。
不过还是少点内卷好，这么搞的目的不就是让资本家有更多用户，少点风险么？都是打工的，那有什么矛盾。
因为前端说的没错，80%以上的后端工作本身就很简单，就是ifelse+curd。这些写后端的天天都觉得从tcp协议栈，到操作系统，到文件系统，到数据结构演算法，到数据持久化，到分散式处理，到消息中间件，到一致性缓存，到负载均衡，到编程语言特性，到编译原理，到cpu流水，到千万并发，到秒百万message等等等，巨庞大的知识链自己没有哪一个不清楚不通晓？……但实际上呢？干的不过是select * from t to json send to kafka，或者get header,body,formvalue from request do some bug and wrtite to response。 天天拿著人大神写基础组件的难度往自己脸上贴金而已。…当然前端也不例外，80%的工作也就V,A.R三架马车捎带上js,html,css三板斧外带会github搜搜组件就完事。难吗？形容难度感觉人人都在写浏览器写vsc实现js标准造方言似的…写代码压根儿就不是个什么难事，难得是把一坨屎一样的产品设计做成成品上线，期间后端通过架构解决一年内拉的屎的兼容和性能问题，前端解决要求一坨屎和另一坨屎形状要一样但是又不能一样的问题，从这点上来说，前端和后端真的都很难。……
我是个后端，我就觉得前端好难，反正我是学不会。
——前端渣渣 死月
软体开发有几条亘古不变的原则：模块化、松耦合、封装底层、向上层透明。
前后端分离就是上面这些原则驱动下的结果。前后端松耦合，没有任何代码层面的关联，只有HTTP网路协议上的通信。后端封装自己的业务逻辑，只给前端暴露出API来，让前端透明调用。
正因为前端看到的只是API，并不会看到封装在内部的复杂业务逻辑。所以就觉得简单。
同样，很多人也会觉得前端简单。因为前端也只暴露出自己的介面(GUI，图形用户介面)，也封装了很多复杂的交互逻辑。所以很多人就认为前端不就是做个网页吗。
同理，有人觉得制造CPU晶元也简单。因为这些东西封装的太好了，对他们来说太透明了，根本感觉不到存在。
推荐阅读：
