后端api接口设计 现在流行的前后端分离项目都使用的是什么前后端框架？
现在流行的前后端分离项目都使用的是什么前后端框架？
开发框架主要分为三个部分：前端、web和持久性，可以自由组合。我单独谈。
在过去，有struts 1、struts 2和spring MVC for java web framework。
目前，只有一个选择：SpringMVC，其他人都不能玩。无论是玩耍、高格、火花还是Struts2。springmvc在用户数量和生态方面与springmvc不一样。
不管其他框架宣传得多好，都不建议投入大量精力。学习框架的设计思路还可以。请直接在生产环境中使用springmvc。spring的基础设施无法与其他框架相比。弹簧靴可用于快速开发。POM可以依赖于enable注释直接使用。
目前，有两种主流的JPA和mybatis。
如果项目是数据建模，请使用mybatis；如果项目是对象建模，请使用JPA。
春天来了。springboot的spring数据子项目应该希望将两者统一起来。不仅两者，而且其野心更大。它希望统一所有持久性层。DB、redis和elastic search都有相应的项目。它希望将所有持久性操作抽象为存储库操作。如果成功，业务逻辑就不需要关心持久层的选择，交换框架也非常方便。
目前，前端框架有三个选项：react、Ag和Vue。
我不喜欢react….的语法。。。。
似乎Ag在中国的知名度不高，所以我们不太关注。
最后的选择是Vue，它简单快速。支持的UI库也比较完善。
如果您想在项目中开发小型程序，建议使用Vue。语法高度一致。你将一眼就知道如何开发小程序。
后端开发完接口才给出接口文档，合理吗？你怎么看？
一个非常好的问题。我是一个web应用程序架构师，多年来一直致力于回答这个问题。欢迎跟我来了解更多。
后端提供接口文档为时已晚，这是合理和不合理的。根据具体情况，总有解决办法。让我谈谈我的观点。
不合理：成熟的技术团队重视功能设计，在编写代码之前有完整的技术文档和功能定义。即使在TDD测试驱动的开发模式下，测试数据已经准备好了，那么接口逻辑就已经确定了接口文档是否编写好了，理清它们是很自然的。
-第一，主观原因。原因是多方面的，比如赶进度，没有时间，不懒得写，甚至在开发前没有仔细设计，在做的时候也有变化。真的没有好办法。
-客观原因：需求在变化，功能在变化，接口也在变化。所以，如果你写了一个文件，它的自然更新和维护？天哪？
有解决方案吗？建议尝试：[1]swagger接口文档，将文档集成到代码中，集成维护文档和修改代码，在修改代码逻辑的同时方便修改文档描述。
2、邮递员界面测试工具，导入导出JSON文件，高效的团队合作。Postman支持各种请求方法和配置环境变量，对返回的结果进行测试和验证，支持批量自动操作，可与自动构建系统集成。
如何正确理解软件系统架构的前后端分离？
首先：软件系统架构的前端和后端分离是近年来比较多的，随着互联网的快速发展，提高了前端和后端交互的响应速度，改善了用户体验，产生了前端和后端分离的架构。例如，Vue和nodejs与微服务架构相结合。前端页面用于呈现UI显示效果，后端负责编写API服务提供数据。Nodejs还可以作为一个桥梁引入，通过后端API连接JSON输出，并返回前端进行页面显示。
其次，基于前后端分离的架构，一方面提高了响应速度，数据计算过程在中间层处理，在前端显示；避免了传统的大数据量请求服务器的压力，性能也得到了提高中间层内部处理拼接，采用多组件、分片、分卡方式实现并行加载和显示，在非WiFi 3G和2G的弱网络环境下性能提高，优势更加明显，模板并行加载、优先加载、优先显示，改善用户的互动体验。
最后：从经典的MVC架构到SSM和SSH的Java框架时代，再到angularjs和Vue等前端框架，虽然技术和架构不断发展和完善，但本质上都是为了更方便的解决需求。前端和后端架构的分离也是一个解耦的过程，它不绑定前端和后端，这也符合SOA的理念，基于企业服务的总线实现了应用系统对接的松耦合，有效地连接和对接了应用、文档和数据在插件和插件模式下，以组件构建、平台构建和架构支撑的方式共同构建企业信息化建设，以更专业的平台实现其专业领域的工作，助力企业信息化发展。
怎么看待一些后端程序员不写接口文档，老是以很忙为借口搪塞？
不写接口文档，一般很忙。或者没有时间整理文件。
对于前端和后端的对接，前端开发人员一般需要后端人员提供接口文档，而现在招摇过市的文档完全可以提供这个功能。在许多情况下，后端开发人员集成了一个swagger并自动生成相应的文档。
您可以给后端开发人员一定的时间来学习swagger或将swagger集成到项目中。
版权声明：本文内容由互联网用户自发贡献，本站不承担相关法律责任.如有侵权/违法内容,本站将立刻删除。
