nodejs前后端分离？

前后端分离和不分离哪个速度快

前后端分离开。

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

在前后端分离的应用模式中，后端仅返回前端所需的数据，不再渲染HTML页面，不再控制前端的效果。至于前端用户看到什么效果，从后端请求的数据如何加载到前端中，都由前端自己决定，网页有网页的处理方式，App有App的处理方式，但无论哪种前端，所需的数据基本相同，后端仅需开发一套逻辑对外提供数据即可。

如何在前后端项目突出网络优势

 1. 前后端分离的架构：

        1.前后端不分离：页面和数据都是同一个服务器返回的。

        2.前后端分离：1. 后端服务器，处理请求，加载数据，返回响应

                                 2. 前端服务器，返回页面，数据部分需要从后端加载，发送异步请求。

     2.前后端分离的优势：

         1. 前端：负责页面的显示效果，用户的体验，浏览器的兼容性

             后端： 负责服务器的稳定性并发性，提高服务器性能。

         2. 并行开发，提高开发效率。

         3. 可以利用客户端来处理一部分数据，降低服务器的压力。

         4. 后端返回的错误信息，不直观地展示给用户。

服务器

前端

运维

库存车出售

精选推荐

广告

传统MVC架构和前后端分离架构模式对比

38下载·0评论

2019年2月25日

前后端架构设计

423阅读·0评论·0点赞

2022年5月19日

nginx搭建前后端分离架构

5482阅读·0评论·4点赞

2017年8月14日

前后端分离架构概述

206阅读·0评论·0点赞

2019年6月8日

简单了解前后端分离架构（MVVM）

979阅读·0评论·2点赞

2022年3月2日

前后端基本架构

9385阅读·0评论·3点赞

2017年6月4日

今日必看：超火爆的韩国韩剧APP，赶快下载！

精选推荐

广告

前后端分离架构，超全面详解~

7969阅读·1评论·15点赞

2021年12月28日

电商系统架构总论篇

247阅读·0评论·0点赞

2015年3月28日

前后端分离框架的实用及优点

1874阅读·0评论·2点赞

2019年8月6日

前后端分离架构的特点分别是什么？

622阅读·0评论·0点赞

2022年11月14日

前后端分离架构设计

9507阅读·0评论·3点赞

2017年1月12日

前后端分离开发架构

704阅读·6评论·3点赞

2022年6月7日

Node.js 做 Web 后端优势为什么这么大？

2405阅读·0评论·1点赞

2021年3月6日

基于NodeJS的前后端分离

5207阅读·0评论·3点赞

2014年5月13日

手把手搭建前后端开发框架

4273阅读·48评论·33点赞

2021年8月18日

前后端分离技术——前端框架

3320阅读·2评论·2点赞

2022年4月18日

前后端分离架构技术

3763阅读·0评论·0点赞

2022年3月9日

前后端分离的优势是什么？

3257阅读·0评论·2点赞

2020年12月9日

后端技术体系框架

5101阅读·0评论·2点赞

2021年8月28日

去首页

看看更多热门内容

如何正确理解软件系统架构的前后端分离？

首先：软件系统架构的前后端分离更多是在近几年伴随互联网的盛行为提高前端与后端交互的响应速率，提升用户的体验进行衍生出了前后端分离架构。如：Vue、NodeJS与微服务架构结合。前端页面进行UI展示效果渲染，后端负责编写API服务进行数据提供，也可以引入NodeJS来作为桥梁架接后端API输出的JSON，返回前端进行页面展现。

其次：基于前后端分离架构一方面提升响应速度，将数据计算的过程在中间层处理，前端进行展示；避免传统的大量数据请求服务器的压力基于中间层在内部处理拼接完成，性能得到了提升；以多组件、片段、卡片的模式实现并行的加载、显示，在非WiFI的3G、2G的弱网络环境下优势更为明显，模板并行加载，优先加载优先显示，提升用户的交互体验。

最后：从经典的MVC架构到SSM、SSH的Java框架时代，再到前端框架如：AngularJS、Vue等，虽然技术、架构一直在演变进步本质上均是为了更方便的解决需求，前后端分离架构更多的也是实现解耦的过程，不将前端与后端绑定，这也与SOA的理念是相吻合的，基于企业服务总线实现应用系统对接的松耦合，以插拔的模式将应用、单据、数据进行有效的连通与对接，以组件构建、平台搭建、架构支撑的模式共同铸建企业的信息化建设，以更专业的平台实现其专业领域的工作，助力企业信息化的发展。

nodejs-koa2（mvc模式）前后端分离 前端设计

前后端分离，前端nodejs运行环境，使用koa2集成负责资源分配与用户交互，实现token验证用户身份，路由控制。等！

自行 百度 解决；

"program": "${workspaceFolder}\app.js"

此处就是是将app.js作为启动文件。${workspaceFolder}代表根目录，vsc启动时会在根目录下找到并加载app.js文件。

参数介绍： name 项目名称、 version 版本号、 description 项目描述、 main 项目启动文件、 scripts 启动快捷设置， author 作者， dependencies 第3方中间件名称及版本。

最重要的

“ dependencies ”这里添加一些要用到的包，以上是这次要用到的所有的包，版本自己更改。

“ scripts ”这里是一些nodejs的便捷命令，上线的时候会用到，直接在终端中，package.json同级目录 ，执行‘npm start’ 即 可启动app.js。

别的没啥太大作用瞎写即可。

启动相关配置，封装到config/init.js中，启动文件直接引用即可

3-6-1、init.js项目核心。

异常友好处理方法封装

路由配置

视图渲染

核心集成

3-6-2、config.js项目参数配置。为什么不用json文件 因为json不能加注释

3-6-3、token.js项目token相关方法封装。

执行后项目结构会增加两个文件

新增

src/hello.js。

views/index.html

浏览器访问：

输入值获取token

获取的token如图：

先不用带token进行访问: hello/jiaobaba,被token拦截，返回401

带上token访问： hello/jiaobaba

测试页面渲染，及跳转html页面，直接访问 /views

结束！！！！！！

需要源码联系我

前后端分离方案以及技术选型

作者：关开发

一.什么是前后端分离？

理解前后端分离大概可以从3个方面理解：

1. 交互形式

2. 代码组织形式

3. 开发模式与流程

1.1 交互形式

前后端不分离

后端将数据和页面组装、渲染好了之后，向浏览器输出最终的html；浏览器接收到后会解析html，解析引入的css、执行js脚本，完成最终的页面展示。

前后端分离

后端只需要和前端约定好接收以及返回的数据格式（一般用JSON格式），向前端提供API接口。前端就可以通过HTTP请求调用API的方式进行交互。前端获取到数据后，进行页面组装、渲染，最终在浏览器呈现。

1.2 代码组织形式

前后端不分离

在web应用早期的时候，前端页面以及后台业务数据处理的代码都放在一个工程下，甚至放在同一目录下，前端页面夹杂着后端代码。前、后端开发工程师都需要把整套代码导入开发工具才能开发。此阶段下前后端代码以及工作耦合度太高，前端不能独立开发和测试，后端人员也要依赖前端完成页面后才能完成开发。最糟糕的情况是前端工程师需要会后端模板技术（jsp），后端工程师还要会点前端技术，需要口头说明页面数据接口，才能配合完成开发。否则前端只能当一个“切图仔”，只输出HTML、CSS、以及很少量与业务逻辑无关的js；然后由后端转化为后端jsp，并且还要写业务的js代码。

前后端分离

前后端代码放在不同的工程下，前端代码可以独立开发，通过mock/easy-mock技术模拟后端API服务可以独立运行、测试；后端代码也可以独立开发，运行、测试，通过swagger技术能自动生成API文档供前端阅读，还可以进行自动化接口测试，保证API的可用性，降低集成风险。

1.3 开发模式与流程

前后端不分离

在项目开发阶段，前端根据原型和UI设计稿，编写HTML、CSS以及少量与业务无关的js（纯效果那些），完成后交给后台人员，后台人员将HTML转为jsp，并通过JSP的模板语法进行数据绑定以及一些逻辑操作。后台完成后，将全部代码打包，包含前端代码、后端代码打成一个war，然后部署到同一台服务器运行。顶多做一下动静分离，也就是把图片、css、js分开部署到nginx。

具体开发流程如下：图略

前后端分离

实现前后端分离之后，前端根据原型和UI设计稿编写HTML、CSS以及少量与业务无关的js（纯效果那些），后端也同时根据原型进行API设计，并与前端协定API数据规范。等到后台API完成，或仅仅是API数据规范设定完成之后。前端即可通过HTTP调用API，或通过mock数据完成数据组装以及业务逻辑编写。前后端可以并行，或者前端先行于后端开发了。

具体开发流程如下：图略

二、前后端分离的好处与坏处。

从上面3个方面对比了之后，前后端分离架构和传统的web架构相比，有很大的变化，看起来好处多多。到底是分还是不分，我们还是要理性分析是否值得才去做。

从目前应用软件开发的发展趋势来看，主要有两方面需要注意：

· 越来越注重用户体验，随着互联网的发展，开始多终端化。

· 大型应用架构模式正在向云化、微服务化发展。

我们主要通过前后端分离架构，为我们带来以下四个方面的提升：

· 为优质产品打造精益团队

通过将开发团队前后端分离化，让前后端工程师只需要专注于前端或后端的开发工作，是的前后端工程师实现自治，培养其独特的技术特性，然后构建出一个全栈式的精益开发团队。

· 提升开发效率

前后端分离以后，可以实现前后端代码的解耦，只要前后端沟通约定好应用所需接口以及接口参数，便可以开始并行开发，无需等待对方的开发工作结束。与此同时，即使需求发生变更，只要接口与数据格式不变，后端开发人员就不需要修改代码，只要前端进行变动即可。如此一来整个应用的开发效率必然会有质的提升。

· 完美应对复杂多变的前端需求

如果开发团队能完成前后端分离的转型，打造优秀的前后端团队，开发独立化，让开发人员做到专注专精，开发能力必然会有所提升，能够完美应对各种复杂多变的前端需求。

· 增强代码可维护性

前后端分离后，应用的代码不再是前后端混合，只有在运行期才会有调用依赖关系。应用代码将会变得整洁清晰，不论是代码阅读还是代码维护都会比以前轻松。

那么前后端分离有什么不好的地方吗？我目前是没有想到，除非你说会增加前端团队的配备，后端工程师会变的不全能。。。

二、前后端分离架构方案。

实现前后端分离，主要是前端的技术架构变化较大，后端主要变为restfull 风格API，然后加上Swagger技术自动生成在线接口文档就差不多了。

对于目前用于前后端分离方案的前端技术架构主要有两种：

· 传统SPA

· 服务端渲染SSR

2.1 传统SPA

传统SPA指的是单页面应用，也就是整个网站只有一个页面，所有功能都通过这一个页面来呈现。因为一个人的肉眼，某一个时间点看一个页面，既然如此何必要不同功能做多个页面呢？只保留一个页面作为模板，然后通过路由跳转来更新这个模板页面的内容不就可以了吗？确实如此，现在通过reac全家桶、tvue全家桶，模块化、路由、wabpack等技术轻而易举就能实现一个单页面应用。

单页面应用的运行流程

1.用户通过浏览器访问网站url

2.单页面的html文件（index.html）被下载到浏览器，接着下载html里面引用的css，js。

3.css，js下载到浏览器完成之后，浏览器开始解析执行js向后端服务异步请求数据。

4.请求数据完成后，进行数据绑定、渲染，最终在用户浏览器呈现完整的页面。

2.2 服务端渲染

服务端渲染的方案指的是数据绑定，渲染等工作都放在服务端完成，服务端向浏览器输出最终的html。大家看完这个是不是有个疑问，这不是又回到了前后端不分离的时代了吗？答案是否定的，因为这里的服务端是用来执行前端数据绑定、渲染的，也就是把浏览器的一部分工作分担到了服务端。而目前具备这只种能力的服务端是NodeJs服务端。

它的原理其实就是在浏览器与前端代码中间插入了一个NodeJs服务端。浏览器请求前端页面时，会先经过NodeJS服务端，由NodeJs去读取前端页面，并执行异步后端API，获取到数据后进行页面数据绑定，渲染等工作，完成一个最终的html然后返回浏览器，最后浏览器进行展示。

服务端渲染应用的运行流程：

1.用户通过浏览器访问网站url

2.NodeJS服务端接收到请求，读取到对应的前端html，css，js。

3.NodeJS解析执行js向后端API异步请求数据。

4.NodeJs请求数据完成之后，进行数据绑定、渲染，得到一个最终的html。

5.NodeJs向浏览器输出html，浏览器进行展示。

PS：其实本质就是把前端编写成一个nodeJs的服务端web应用。实施服务端渲染后，我们最终运行的是一个Nodejs服务端应用。而单页面应用是把静态页面部署到静态资源服务器进行运行。

看到这里，你是否又有疑问，为什么要这么麻烦搞服务端渲染呢？

2.3 SPA与服务端渲染方案对比

SPA的优点是开发简单，部署简单；缺点是首次加载较慢，需要较好的网络，不友好的SEO。

so，以下就是使用服务端渲染的理由了（摘取vue官方说法）：

与传统 SPA (单页应用程序 (Single-Page Application)) 相比，服务器端渲染 (SSR) 的优势主要在于：

· 更好的 SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面。

请注意，截至目前，Google 和 Bing 可以很好对同步 JavaScript 应用程序进行索引。在这里，同步是关键。如果你的应用程序初始展示 loading 菊花图，然后通过 Ajax 获取内容，抓取工具并不会等待异步完成后再行抓取页面内容。也就是说，如果 SEO 对你的站点至关重要，而你的页面又是异步获取内容，则你可能需要服务器端渲染(SSR)解决此问题。

· 更快的内容到达时间 (time-to-content)，特别是对于缓慢的网络情况或运行缓慢的设备。

无需等待所有的 JavaScript 都完成下载并执行，才显示服务器渲染的标记，所以你的用户将会更快速地看到完整渲染的页面。通常可以产生更好的用户体验，并且对于那些「内容到达时间(time-to-content) 与转化率直接相关」的应用程序而言，服务器端渲染 (SSR) 至关重要。

使用服务器端渲染 (SSR) 时还需要有一些权衡之处：

· 开发条件所限。浏览器特定的代码，只能在某些生命周期钩子函数 (lifecycle hook) 中使用；一些外部扩展库 (external library) 可能需要特殊处理，才能在服务器渲染应用程序中运行。

· 涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应用程序 (SPA) 不同，服务器渲染应用程序，需要处于 Node.js server 运行环境。

· 更多的服务器端负载。在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server 更加大量占用 CPU 资源 (CPU-intensive - CPU 密集)，因此如果你预料在高流量环境 (high traffic) 下使用，请准备相应的服务器负载，并明智地采用缓存策略。

以vue为例，实施服务端渲染可以查看官方指南： ，或选择Nuxt.js

2.4 预渲染技术

如果你调研服务器端渲染 (SSR) 只是用来改善少数营销页面（例如 /, /about, /contact 等）的 SEO，那么你可能需要预渲染。无需使用 web 服务器实时动态编译 HTML，而是使用预渲染方式，在构建时 (build time) 简单地生成针对特定路由的静态 HTML 文件。优点是设置预渲染更简单，并可以将你的前端作为一个完全静态的站点。

如果你使用 webpack，你可以使用 prerender-spa-plugin 轻松地添加预渲染。它已经被 Vue 应用程序广泛测试 - 事实上，作者是 Vue 核心团队的成员。

prerender-spa-plugin:

三、前后端分离技术选型

- artTemplate + bootstrap（不推荐， 不算完全前后端分离）

- vue全家桶（推荐）

- react全家桶 （推荐，生态全）