python前后端分离开发,python和vue实现前后端分离
有网友问：据说前端分离是因为前端人集中在前端，后端人集中在后端。如果项目比较简单，一共几个人在开发，那么前端和后端的分离有意义吗？
今天我们邀请了四位精制技术的前端和后端工程师，结合自己的项目运营经验，与大家分享他们对于小项目前后端实际体验的总结，希望对你有所帮助。
01
淘大技术部
小项目是否需要前后端分离，取决于哪种方式能够『时间最快、成本最小地完成当前的业务需求』。
脱离实际情况谈这个问题是没有意义的。毕竟技术架构的选择需要服务于业务。
小项目有多小？它的生命周期有多长？是只有很短时间的临时系统，还是未来有可能扩展到大型项目？这个小项目有多少技术人员维护？他们的技术职业是什么？这些都是需要考虑的地方。小项目是否需要前后端分离，取决于哪种方式能够『时间最快、成本最小地完成当前的业务需求』。
我们知道，前后分离是为了让技术人员各司其职，提高效率。成熟的互联网公司也有这样的机制。人力充足，技术人员职责明确，显然无论从开发效率、系统可维护性还是系统可扩展性来说，前后台分离都是最好的。毕竟互联网技术发展到今天，前端和后端都没有当初那么快了。这两种技术之间有很大的差距。前端注重交互和体验，后端注重数据的同步性。
当然，回到后台设置，如何选择要看团队开发者的实际情况。举个例子，如果开发者只有一个PHP工程师，但是他对现代前端框架并不熟悉，一般都是开发PHP页面，HTML/PHP/JS非常混乱，那么很明显这个时候前端和后端就会分离。
但是从上面的例子也可以看出，前后端不分离的情况已经是落后的生产方式了。今天，根据笔者的经验，即使我在学校工作室创业，也会有尽可能多的技术岗位合作完成项目。即使一个人从事多项工作开发，代码组织模式也基本是前后分离的。过度设计是建筑上的大忌，但有大量的实践证明其在前端和后端分离上的优越性。
作为一个前端Web框架，笔者所接触到的Node.js Web框架是以之前的后端分离为设计原则之一，甚至是Laravel这种经典语言—— PHP中最流行的前端不分离的Web框架之一。原因是现代前端技术的复杂性不适合与后端结合，从开发阶段的工程架构到提高页面性能的各种优化措施。
因此，我们的结论保持不变。前端和后端是否需要分离，取决于用什么方法可以“以最快的速度降低成本”来满足当前的业务需求。当然，考虑到实际情况，将前后端分开是比较常见、先进、合理的方式。
总之，目前流行的云集成APP应用开发方法看似不一致，但其实核心原理是一样的。得益于Serverless，前端工程师可以在专注于前端UI的基础上，更深入地获取数据处理权限，某种意义上是一种更高效的开发方式。给并发、扩展、服务器迁移等。更接近后端的无服务器容器来解决。这也是前后端分开的做法。我们认为，在小项目中，可以大胆尝试云的集成开发。
02
淘技术部门被摧毁。
358 www.Sina.com/http://www.Sina.com/In大多数场景，我觉得前后端分离总比不分离好。
然后从用户体验、开发效率、运输效率三个主要场景分析前端和后端是否存在分离。
www.Sina.com/http://www.Sina.com/http://www.Sina.com 3358号
在制作店面订单系统时，用户对系统的基本要求是界面美观，加载速度快。对于侧重于这些前端效果的项目，使用传统的前端和后端集成项目。在界面交互方面，除非有专业的前端程序员，否则复杂的前端交互逻辑都会转换成JSP。此外，如果加入丰富的主题和效果，UI很可能会描绘保时捷，开发将非常沙。想象一下10年前网站的风格。在加载速度上，由于所有资源都放在服务器端，第一次加载需要加载大量的js、css和静态资源，没有浏览器缓存。这在今天几乎是不可接受的。即使将资源放在Ngnix服务器上，也无法实现最终的加速。对于前端分离的开发模式，前端项目负责前端，利用现有的前端脚手架可以直接实现界面交互。业内已经有专业设计师设计的UI框架，都实现了丰富的动态效果和复杂的交互，并且可以一键部署。在加载速度上，前端资源可以单独释放部署，预热并最终加速cdn。
如果你在做一个只能在用户的服务器界面上调用的工具项目，那么用户对系统的基本要求就是能够理解并成功操作。在这些注重服务器端结果的项目中，当功能改变的概率较低时，完全可以使用前端集成开发模式，以光速在线开发，通过一个系统解决所有问题。
如果项目侧重于前端交互，建议使用前端和后端隔离。
专注于服务器端功能，无需复杂交互，前端集成速度更快。它的服务器是订单支付的基本逻辑。显然，基于传统的jsp模式实现交互复杂的前端页面是非常困难的。第一个难点在于页面开发，先开发html，再从服务器转换成JSP。实现功能的复杂程度已经很高了，美观程度也无法保证。这对前端的技术要求很高。第二个难点在于流畅度。前端和后端集成项目的加载页面需要通过Nginx打到服务器。如果第一次没有流量缓冲，静态资源可能需要多次下载，所以页面加载很慢，服务器无法解决这个问题。如果前端和后端分离，可以利用现有的前端脚手架直接实现前端页面。各种优秀的前端框架已经支持大部分UI组件，集成了动态、风格和交互，绑定了服务器数据集。在加载速度上，前端资源可以通过cdn加速，实现快速加载。当然，如果是开发一个内部使用的工具项目，前端逻辑简单，改动不大，那么使用前端和后端集成的效率可能会更高。
对于侧重前端效果的项目，建议前后端分离。
开发效率
端到端集成项目只在前端接口交互简单、变化频率低的服务型项目中略占优势，因为这类项目的核心是服务，前端只是一个服务调用入口，只是比邮差调用接口产品化一点点。不需要前端人力，服务器开发方便。在这种场景下使用jsp成本最低，效率最高。
对于任何需要前端接口和交互，并且会长期迭代的项目，无论项目大小，使用前端分离的效率都要高于前端和后端集成的效率。前端分离可以通过定义服务接口并行开发，互不影响，达到事半功倍的效果。专业的人做专业的事，专业领域有更专业的工具，可以达到事半功倍的效果。
前端集成的应用场景非常有限。任何需要前端交互的项目，都应该通过前端和后端分离的方式进行开发。
运维效率
对于前端集成项目，前端是全耦合的，一次部署后前端可以同时在线。但是一旦服务器宕机，前端页面无法显示，影响所有用户。此外，服务器和前端迭代都需要重新
对于前端和后端分离的项目，前端和后端由不同的应用承载，迭代和发布可以独立进行，实现完全解耦，几乎没有依赖。服务器宕机时，前端底页的交互可以减少影响面，独立运维大大降低迭代风险。到目前为止，运维工具已经非常完善，成本非常低。相对于很多风险，独立运维带来的成本增加可以忽略不计。大部分场景下前端分离的运维效率高于前端集成。
综上所述，在目前的技术环境下，前端分离是大势所趋，在用户体验、开发效率、运维效率等方面都领先于前端整合方案。随着互联网技术的深度发展，行业对技术人员的要求从技术广度向技术深度转变，专业的人做专业的事。所以即使是小项目也还是建议前端分离！
03
淘技术部门的后半部分
其实真正实践下来，分离也很快的，尝试一下就知道了。先说结论：
基于现有的前端技术和运维能力，即使是小项目，也建议将前端和后端分开；当然，如果10年前技术还不成熟，不把前端和后端分开也是项目快速上线的较好手段。
先谈下何为小项目
开发周期短的项目(两天后上线)？
维护时间短的项目(这个项目这次会急用，下次不用)？
简单的功能项(只是简单的数据库查询，以后不会有需求变化)？
核心问题就是小项目的成本对比？
我的观点：项目无论大小，要实现的产品功能肯定不会减少，基础开发工作量相差不大，所以比较前后端的运维成本。如果有运维声明就更好了。根据我的工作经验，运维成本没有太大区别。
接下来就要谈谈分离的优点了
必须要说的是耦合问题；端到端的分离很自然的理清了双方的交互/开发边界，面向json的数据对接。
联调成本大大节省，前后端可以并行开发，问题定位更快更清晰。
可维护性更高，更便于后期的重构。
可读性更强等等。
这个问题其实挺简单的。有些人认为小项目简单易行。而且先入为主的想法认为不分离会更快。其实真的练起来，很快就分开了。试试吧。
04
淘大技术部
持续交付且周期越长的项目，前后端分离效果越到后期优势越明显
这个问题往往更多的是由项目是否需要持续交付目的和开发周期的长短决定的。投放周期越长，后期前后端分离效果越明显。
通常前端和后端关注和解决的问题是不同的。前端注重交互和体验，忽视业务关系，需要有随时调整投放的能力；后端专注于数据逻辑，专注于业务逻辑，相对稳定地决定一切。
那么是否需要分离取决于项目交付的需求和频率以及对项目的影响程度。
一般来说，在真实的业务场景中，前端和后端开发的分离通常是更好的选择：
可以同步开发，降低交付延迟的风险。
完整的界面和文档，降低双方理解和沟通的成本。
提前了解项目的风险和难度，有更清晰的心理预期。
维护、维护或保养
对于第一点，在多人的项目中，协助可以获得更多的开发时间，这绝对是降低延期风险最有效的手段。其次，前后端分离可以更好的解决依赖的困境，每个开发进度都可以通过各种工具或者文档进行。最重要的是，前后端分离后，采用的技术在实现和选择上没有束缚。为后期维护带来方便。
结语
在大多数情况下
郑重声明：本文由网友发布，不代表盛行IT的观点，版权归原作者所有，仅为传播更多信息之目的，如有侵权请联系，我们将第一时间修改或删除，多谢。