前后端分不分离

前后端分离的优点

  1. 提高开发效率
    前后端各负其责, 前端和后端都做自己擅长的事情,不互相依赖,开发效率更快,而且分工比较均衡,会大大提高开发效率
  2. 用户访问速度快,提升页面性能,优化用户体验
    没有页面之间的跳转,资源都在同一个页面里面,无刷线加载数据,页面片段间的切换快,使用户体验上升了一大截;前后端不分离,稍不留神会触发浏览器的重排和重绘,加载速度慢,降低用户的体验
  3. 增强代码可维护性,降低维护成本,改善代码的质量
    前后端不分离,代码较为繁杂,维护起来难度大,成本高
  4. 减轻了后端服务器的请求压力
    公共资源只需要加载一次,减少了HTTP请求数
  5. 同一套后端程序代码,不用修改就可以用于Web界面、手机、平板等多种客户端

前后端分离的缺点

  1. 首屏渲染的时间长
    将多个页面的资源打包糅合到一个页面,这个页面一开始需要加载的东西会非常多,而网速是一定的,所以会导致首屏渲染时间很长,首屏 渲染后,就是无刷新更新,用户体验相对较好不利于搜索引擎的优化(SEO)
  2. 现有的搜索引擎都是通过爬虫工具来爬取各个网站的信息,这些爬虫工具一般只能爬取页面上(HTML)的内容,而前后端分离,前端的数据基本上都是存放在行为逻辑(JavaScript)文件中,爬虫工具无法爬取,无法分析出你网站到底有什么内容,无法与用户输入的关键词做关联,最终排名就低
  3. 不能使用浏览器里面的前进后退功能
  4. 一些版本较低的浏览器对其支持度不足

总结:
是否要分离,由具体业务来决定
若需要搜索引擎带来流量,则不分离
若需要App和后端交互,必须分离
若需要用户登录且不能由搜索引擎抓取,可以选择分离
若需要网站前端效果绚丽,跨设备兼容要求高,可以选择分离
若网站尚处于原始开发模式,数据逻辑与表现逻辑混杂不清,可以选择分离

转载 https://blog.csdn.net/ccsundhine/article/details/111034332

这里是经常容易被混淆的一些概念。在说前后端分离之前,要先弄清楚:

什么是前端?

什么是后端?

什么前后端不分离?

什么是动态数据?

什么是静态文件?

什么是动静分离?

然后,什么是前后端分离就可以很清楚了。

1所以,先来看第一个问题:什么是前端?这又可以分解成几个小问题:

JS是前端么?

只要用JS写的,都是前端么?

只要是前端工程师写的,都是前端么?

大前端就是指的用JS语言写的前端,哪怕它是运行在服务器那一端么?

App算前端么?

Html+CSS算前端么?

小程序算前端么?

ReactNative算前端么?

这些问题其实会困扰很多人,每一个人的想法也是不一样的。

通常情况下,我们说的前端,都是指浏览器这一端,浏览器这一端,又在通常情况下,都是用JS来实现的,所以又会引申为,用JS写的大部分程序都是前端,包括App,小程序,H5等。而NodeJS出现之后,用NodeJS写的后端部分,也会被人归类为前端,为了区分之前的前端,就给他们起了一个名字,叫做“大前端”。

但,这种以语言为分界点去区分前后端,真的合理么?

在过去,我们是不分前后端的,无论是Java还是JS,全都是一个人来写。

2倒底是什么原因让我们开始区分前后端了?

第一个,是可以并行开发。前后端的进度互不影响,在过去,前后端不分离的情况下,前端的工作量相对较少,一个前端可以对四个后端。可以理解为,前端花了一周时间写好了静态页面,只需要调几个Ajax接口,不需要路由,也不需要渲染,所以他可以把时间继续在下一个项目里。

第二个,是成本问题。在过去,后端的成本还是比前端要高一些。同样的工作,如果能拆给两个人做,一个成本高一点,一个成本低一点,能接受。

第三个,CSS太难了。JS还好,和后端语言在对技能的训练上相差不大,可是。。CSS是什么鬼?记住那么多的属性,和Hash算法有关系吗?

所以才分成了前后端,而Html+CSS+JS,都是在浏览器端执行,统一称之为前端。

而Java,C,Python,PHP这些可以运行在服务器端的,统一称之为后端。

所以前后端的定义,不应该是以语言来定义,而是应该以它的运行环境,如果是在服务器端,就应该被称之为后端,代表着你看不见,摸不着。而如果运行在用户端,就应该被称之为前端,代表你是可以看得到的。

按照这种说法,前端和后端就分的很清楚了。

3我们接下来再看,什么叫前后端不分离。

在Android和IOS没有出现的年代,还有一种流行的说法,叫做C/S和B/S架构。现在已经很少有人提了,如果你知道,这又是一个暴露年龄的名词。

C/S架构,指的就是Client-Server,意思就是在桌面程序上,有一个客户端,然后远程连接服务器端,用Socket或者是Http传输数据。

而B/S架构,就是指通过浏览器访问,不用提前安装一个客户端。

B/S架构,曾一度被认为是C/S架构的替代者,好处就是无须安装,简单方便,研发速度也快。

在那个时候,JSP,ASP,PHP还被称为三驾马车。

那个时候的写法,就是后端去控制一切。http://game.ptteng.com 是我很久之前写的一个前后端不分离的网站,可以看到是一个完整的Html页,有兴趣大家可以去看一下。

这是什么意思呢?就是指,浏览器访问的是一个完整的Html网页,而这个网页呢,并不是一个静态的网页,写好在服务器上的,而是应用程序从数据库里取数据生成的,动态网页。

所以,前后端不分离的交互方式很简单,就是浏览器发请求,服务器端给出一个完整的网页,浏览器再发请求,服务器端再给出一个完整的网页。

坏处很明显,传输的重复数据比较多,网络又会有延迟。所以有没有办法,只传送必要的数据?

这是Ajax的起源。

Ajax就是只传递数据,不传递整个网页。这也是被用来在翻页,注册,发送验证码等场景,但也仅仅止步于此了。

怎么样提升访问的性能,更多的人用的是网页静态化的技术。

就是把所有的动态数据都提前生成很多很多静态的Html网页,这样就避免了从数据库里取数据的时间。

这种方式本来不会发生变化,大家都习惯了这种做法。

突然有一天,苹果说我们发布了Iphone。这个Iphone居然可以让程序运行在手机上。

很有一种C/S架构的感觉。

只是过去的C/S架构并没有大规模的应用在互联网上,多数上传统行业,互联网还是前后端不分离的多一些。

可是后端在写这些被称之为客户端的程序,就觉得太爽了。

过去还要套页面,还要控制跳转,现在呢?

面向Api编程啊,只需要告诉我Api是什么,我的每一个Api都是独立的,互相之间没有依赖。

App自己做控制,做缓存,做跳转,做交互。

后端神马都不用管,只需要保证自己的Api接口是好的。Postman很好用啊。还能自我验证。

但是不爽的在哪里?

就是针对客户端会有一个ApiServer,然后针对网页,还会有一个Home。

两个功能经常会一致,但是后端人员要写两套代码。一套是生成Json的,一套是生成Html网页的。

前端JS也很羡慕客户端的开发人员啊。过去前端就是一个打边角料的角色,只能写写静态文件,看着后端去把页面套的错误百出,偶尔写个校验,发送一个请求。

可是人家客户端!跟后端就没什么废话说,你只需要把API保证正确,剩下的全部我来。

两者之间的交互简单方便,快捷省力。多好的方式?

所以网页能否和客户端一样,也把决策权拿自己手里?

实际上是可以的啊。Angular就这么干了!

这就是SPA的含义之一,总之,到这个时候,前后端分离的意义才展示出来。

4再说什么叫做动静分离,这里还牵涉到一个叫做打版本的概念。

一般而言,会分成开发,测试和线上的环境。

在SVN的年代,分成Trunk,Branches和Tags。

Tag,就是一个版本的快照。

为什么要有版本的快照?是希望能够在发生错误的时候回滚。

所以在前后端不分离的时候,如果发现网页上有一个错别字,怎么办?

不好意思,拉一个分支出来,重新打Tag,前端后端的代码一起打。不允许你手动修改。

但是后端的发布是需要重启服务的啊。

为嘛我改一个错别字就需要重启服务?有没有办法让后端和前端不在一起部署?

互相独立?前端你写错字了,你自己来,反正 你又不需要重启?

这就是动静分离的起源。

把动态程序和静态程序分开,大家互相不影响,各自部署分开。

现在,你能区分出来这些概念了吗?
————————————————
版权声明:本文为CSDN博主「七彩极光」的原创文章,遵循CC 4.0 BY-SA版权协议,转载请附上原文出处链接及本声明。
原文链接:https://blog.csdn.net/weixin_36168996/article/details/113367236

https://m.php.cn/article/466400.html

区别:前后端不分离中,前端页面看到的效果都是由后端控制,由后端渲染页面或重定向,即后端需要控制前端的展示,前端与后端的耦合度很高。前后端分离中,后端仅返回前端所需的数据,不再渲染HTML页面,不再控制前端的效果,前端与后端的耦合度相对较低。

一、前后端分离的概念

1、前后端分离

前后端分离是一种架构模式,说通俗点就是后端项目里面看不到页面(JSP | HTML),后端给前端提供接口,前端调用后端提供的 REST 风格接口就行,前端专注写页面(html|jsp)和渲染(JS|CSS|各种前端框架);后端专注写代码就行。
前后端分离的核心:后台提供数据,前端负责显示
1、软件架构模式

最熟悉MVC设计模式,Model—View-Controller 模型-视图-控制器

它是怎么工作的?通俗来说:你在页面输入一个网址(请求-Request),这个网址跑到哪里去了呢?就去调用接口
(REST风格),这个接口其实就是访问后端的一段代码(方法),后端有很多方法。
如何确定访问的是哪个方法?就是接口定义好的,比如:177.25.26.7/idp/user/login,这里面的idp就表示一
个服务(一个工程),user表示一个类,login表示具体要调用的那个方法,你一旦回车,就直接调用了后端这个方法,后端这个方法就去数据库(MySQL|Oracle|其他)取数据,数据库表中每一行数据就表示一个对象,也就是一个JavaBean,最终用pojo方式存到集合框架 (List|Map|Set|等)中,方法把这个集合返回,那么调用这个接口的结果就是会响(Response)给你一个结果集,前端就拿到了这个数据,然后通过页面(html|Jsp)展现出来,这个用户看到的就是View层做的事情。
2、前后端分离的原因

在以前,听说 TDD (Test-driven development,测试驱动开发) 可以改善代码的质量,我们便实施了 TDD;接着,听说 BDD (Behavior-driven development,行为驱动开发) 可以交付符合业务需求的软件,我们便实施了 BDD;后来,听说 DDD (Domain-driven design,领域驱动设计) 可以分离业务代码与基础代码,我们便实施了 DDD。今天,听说了前后端分离很流行,于是我们就实施了前后端分离——这就是传说中的 HDD(Hype-driven Development,热闹驱动开发)。

过程: TDD -》 BDD -》 DDD =》 HDD

3、前后端分离的优点

前后端分离则可以很好的解决前后端分工不均的问题,将更多的交互逻辑分配给前端来处理,而后端则可以专注于其本职工作,比如提供API接口,进行权限控制以及进行运算工作。而前端开发人员则可以利用nodejs来搭建自己的本地服务器,直接在本地开发,然后通过一些插件来将api请求转发到后台,这样就可以完全模拟线上的场景,并且与后台解耦。前端可以独立完成与用户交互的整一个过程,两者都可以同时开工,不互相依赖,开发效率更快,而且分工比较均衡。

总结优点如下:

提升开发效率
完美应对复杂多变的前端需求
增强代码可维护性
二、前后端分离和前后端不分离的区别

1、前后端不分离

在前后端不分离的应用模式中,前端页面看到的效果都是由后端控制,由后端渲染页面或重定向,也就是后端需要控制前端的展示,前端与后端的耦合度很高。
这种应用模式比较适合纯网页应用,但是当后端对接App时,App可能并不需要后端返回一个HTML网页,而仅仅是数据本身,所以后端原本返回网页的接口不再适用于前端App应用,为了对接App后端还需再开发一套接口。
2、前后端分离

在前后端分离的应用模式中,后端仅返回前端所需的数据,不再渲染HTML页面,不再控制前端的效果。至于前端用户看到什么效果,从后端请求的数据如何加载到前端中,都由前端自己决定,网页有网页的处理方式,App有App的处理方式,但无论哪种前端,所需的数据基本相同,后端仅需开发一套逻辑对外提供数据即可。
在前后端分离的应用模式中 ,前端与后端的耦合度相对较低。
在前后端分离的应用模式中,我们通常将后端开发的每个视图都称为一个接口,或者API,前端通过访问接口来对数据进行增删改查。

你可能感兴趣的:(python,爬虫,前端)