前后端要不要分离以及如何做

前后端分离要不要搞?
这个我觉得按照康威定律办就好了, 前后端如果是两拨人, 不要多想一定要分离, 如果是一拨人, 确定前后端是否要分离需要算账 , 收益是它会强制我们按照服务的理念指导系统设计, 将来的微服务也就顺理成章, 代价就是架构复杂了, 开发和运维都有些成本.

下面假定我们确定前后端要分离, 就要考虑实现的方案/技术选型/常见问题处理.

=============================
前后端分离的几种实现思路
=============================
思路1: 前端 Nginx(vue+element UI+axios) 和 后端Tomcat(Spring Boot)
思路2: 前端 Nginx(vue+element UI+axios) 和 中间层(NodeJS) 和 后端Tomcat(Spring Boot)
思路3: 前端 Nginx(vue+element UI+axios) 和 中间层Tomcat(Spring Boot路由/Render)  和 后端Tomcat(Spring Boot)

简单分析:
思路1: html render 是由前端完成, 前端通过ajax方式完成数据请求, 主要问题有: ajax 需要写死后端服务地址, 想象一下, 如果UI需要访问10个后端服务, 就需要写死10个地址, 同时没法利用上后端的服务发现技术.  前后端未分离情况下不存在这些问题. 一个解决方法是, 引入API网管.

思路2: 这是淘宝前后端分离的实践, html render 由中间层 NodeJS 完成, 中间层同时完成数据转发和路由设计工作, 也就是承担了MVC中的Controller. ajax调用不需要写死, 可以在NodeJS层从服务发现中动态提供后端服务地址.

思路3: 和思路2差不多, 就是将NodeJS换成 SpringBoot 而已. 这个思路相比思路2的优点是, 不需要引入一个全新的NodeJS架构.

我个人推荐思路3, 优点是:
1. 在不引入API网管情况下, 能解决前端需要写死后端请求地址的问题.
2. 熟悉 SpringBoot 的技术人员比 NodeJS 要多得多.

图片取自:淘宝前后分离实践

=============================
前后端分离的技术选型
=============================
前端选型, vue+element UI+axios 目前看在国内比较流行.
https://segmentfault.com/a/1190000010167910
https://blog.csdn.net/lgcjava/article/details/75331074

=============================
前后端分离经常碰到的问题
=============================
前后端分离 -- 跨域访问的实现
https://blog.csdn.net/github_33809414/article/details/81774885
https://www.cnblogs.com/hbb0b0/p/8035241.html
https://segmentfault.com/a/1190000012960641

前后端分离 -- 使用axios做网络请求 -- 使用Cookie SESSIONID
https://blog.csdn.net/dodan/article/details/78543912

原文地址:https://www.cnblogs.com/harrychinese/p/front-end.html

时间: 2024-10-09 16:33:59

前后端要不要分离以及如何做的相关文章

架构设计:前后端分离之Web前端架构设计

在前面的文章里我谈到了前后端分离的一些看法,这个看法是从宏观的角度来思考的,没有具体的落地实现,今天我将延续上篇文章的主题,从纯前端的架构设计角度谈谈前后端分离的一种具体实现方案,该方案和我原来设想有了很大的变化,但是核心思想没变,就是控制层是属于Web前端的. 在以前文章里我说道前后端分离的核心在于把mvc的控制层归为前端的一部分,原方案的构想在实际的生产开发里很难做到,我觉得核心还是控制层和视图层的技术异构性,这样后果使得系统改造牵涉面太大,导致在项目团队里,沟通.协调以及管理成本相对较高,

前后端分离及React的一些研究

前言 在对英才网企业线前端不断的完善过程中,我们尝试进行了前后端分离,引入Node环境.以及在使用React的过程中,自行开发DOM渲染框架,解决React兼容低版本IE的问题,在这个过程中,我们有了一些经验和体会,希望本文对您有所帮助. 为什么前后端分离 原有架构下,后端系统基于Java语言实现,通过Velocity模板实现服务器端渲染,前端同学维护静态资源,在维护页面状态时,还需要模板和脚本互传参数,模板中还会有很多UI逻辑,等等,前后端耦合很深,这种模式下开发效率非常低,联调成本非常高,同

前后端分离了,然后呢?(转)

前言 前后端分离已经是业界所共识的一种开发/部署模式了.所谓的前后端分离,并不是传统行业中的按部门划分,一部分人纯做前端(HTML/CSS/JavaScript/Flex),另一部分人纯做后端,因为这种方式是不工作的:比如很多团队采取了后端的模板技术(JSP, FreeMarker, ERB等等),前端的开发和调试需要一个后台Web容器的支持,从而无法做到真正的分离(更不用提在部署的时候,由于动态内容和静态内容混在一起,当设计动态静态分流的时候,处理起来非常麻烦).关于前后端开发的另一个讨论可以

前后端分离实践(一)

前言 最近这一段时间由于Nodejs的逐渐成熟和日趋稳定,越来越多的公司中的前端团队开始尝试使用Nodejs来练一下手,尝一尝鲜. 一般的做法都是将原本属于后端的一部分相对于业务不是很重要的功能迁移到Nodejs上面来,也有一些公司将NodeJS作为前后端分离的一个解决方案去施行.而像淘宝网这类的大型网站也很早的完成了前后端的分离,给我们这样的后来者提供了宝贵的经验. 同样,我们的大网盘团队也早在去年早早就开始了紧锣密布的准备工作,这目前工作也做的差不多了,现在我就来总结一下在过程中遇到的坑点以

浅析前后端分离

大家好,初来乍到,有点小紧张,写得不好的请各位大佬多多批评指正. 我老板是个不懂技术的 boss,前天他找我去负责一个新项目,我内心一想,劳资早受够了这些老古董项目的苦了,这次肯定要按我想法来搞了,开心.这里说一下,我是写Java的,之前一直在公司一直是维护别人写的项目,祖传代码那种,啥玩意都丢在jsp里面,一坨坨的,每天让我在里面改哪些不可描述的代码,此处手动微笑. 第二天,我屁颠屁颠地拿着俺的计划和方案给他看,老板看完眉头一皱,这种前后端完全分离的开发方式我们没做过,为什么要选择这种方式?前

浅谈前后端分离与不分离

前后端的分离与不分离 随着不同终端的兴起,对开发人员的要求越来越高,纯浏览器端的响应式已经不能满足用户体验的高要求,我们往往需要针对不同的终端开发定制的版本,为了提升开发效率,前后端分离的需求越来越被重视,前端主要负责页面的展现和交互逻辑,后端主要负责业务和数据接口,同一份数据接口,我们可以定制开发多个版本. 前后端不分离: 在之前的开发方法,php代码写在HTML中,不存在纯粹的PHP文件和HTML文件,这就是前后端的不分离,也就是php和HTML你中有我我中有你,而在前后端不分离的应用模式中

为什么要进行前后端分离?

一.认识前后端分离 可能很多人会有误解,认为web应用的开发期进行了前后端开发工作的分工就是前后端分离.但其实前后端分离并不只是开发模式,而是web应用的一种架构模式.在开发阶段,前后端工程师约定好数据交互接口,实现并行开发和测试:在运行阶段前后端分离模式需要对web应用进行分离部署,前后端之前使用HTTP或者其他协议进行交互请求. 二.为什么要进行前后端分离 在以前传统的网站开发中,前端一般扮演的只是切图的工作,只是简单地将UI设计师提供的原型图实现成静态的HTML页面,而具体的页面交互逻辑,

你是如何看待前后端分离的?

首先看看前后端分离是什么? "前端"通常指的是,相对来说更接近用户的一端,例如:APP,网页.桌面程序等,在现实开发中大部分情况可以理解为"客户端": "后端"相对来说就更泛化了,可以理解为是为前端提供服务的一端. "分离"顾名思义就是将"前端"和"后端进行分开",但是这里的分开主要从下面几个纬度进行分离 1:架构分离,前端不需要依赖后端架构同时后端也不需要知道前端使用何种架构 2:人员

【前端经典面试题】前后端分离(说一说你理解的前后端分离?)

前言:昨晚面试遇到了这个问题,既然遇到了,找些资料来一起做个总结吧. 1.对前后端分离的误解  在回答这个问题的时候不要钻到某个具体的技术 ,或者某个具体的框架上面→比如ajax异步请求.vue或react等组件化的开发框架.再或者rest接口规范.API接口数据约定等.从某个具体的技术切入来回答对前后端分离的理解本身就是一种局限的看法,所以在回答这个问题的时候应该从以下几个方面展开. 2.为什么要分离?  在以往的很长一段时间里,后端开发才是开发团队里的核心,前端开发往往仅由一小撮人甚至交给后