vscode怎么导出脱离开发环境的文件
vscode按住Ctrl+Shift+P导出脱离开发环境的文件。
导出脱离开发环境可以通过在初始开发环境中打开VSCode并按住Ctrl+Shift+P来显示可用命令列表来实现。
vscode是由微软研发的一款免费、开源的跨平台代码编辑器，目前是前端（网页）开发使用最多的一款软件开发工具。
前后端分离微服务架构如何设计
前端
前端开发人员专注业务的页面呈现，非常注重用户体验度，也是与各种角色打交道最多的。
比如：
一般前端工作包括六个部分：
后端
如果前后端职责划分很清楚的话，后端更多开发工作在于业务接口设计、业务逻辑处理以及数据的持久化存储，并提供详细的接口设计文档给前端开发人员使用。
一般后端工作包括五个部分：
1、与产品经理对接需求
2、业务 API 接口开发：根据根据需求文档进行业务接口开发
4、接口对接：与前端开发人员接口对接
5、前后端联调测试：包括页面展示以及接口数据
6、bug修复
前端开发技术栈
h5 、 css 、 nodejs / vue / angular / react 、 webpack 、 hbuilder / vscode 等
后端开发技术栈
SpringCloud / Springboot 、 SpringMVC 、 ORM 框架、数据库、缓存框架（ Redis ， Codis , Memcached 等），大数据框架（ Hadoop / Spark / hive / Hbase / Storm / ES / Kafka ）等等
技术选型
最好选择成熟稳定，易上手、开发效率高的技术，因为实际项目开发时间是有限的，开发人员没有多少精力放在学习和深度研究技术上。
数据格式
后端开发提供接口设计文档，详细写明每个接口的请求地址、请求参数、响应参数等等；一般采用 REST 风格以 JSON 格式提供数据。
接口设计
一个接口设计的好坏，直接影响到前后端的一些沟通协调问题。
依笔者的经验来看，如果后端接口不稳定，会导致前端开发人员反复修改页面数据呈现。常常出现后端开发说这是前端问题，前端开发说是后端问题，来回扯皮，沟通效率低下。
接口容量问题
一个接口的业务容量大小，往往代表前后端工作量的大小。
如果一个接口的业务容量太小，前端需要分阶段处理的事情就多，尤其是对多个接口 Ajax 异步处理；
如果一个接口的业务容量太大，那么业务耦合性高，万一需求变更，后端程序改动大，不利于程序的扩展。
一、前后端分离的思想要转变
不能老是按照传统WEB（ js/h5/css/ 后端代码放在一个工程）开发思维去看待前后端分离
二、沟通成本问题
以前传统 WEB 开发，开发人员从需求到设计到开发基本上是一个人。
而前后端分离后，前端只负责页面呈现，后端更注重业务逻辑处理以及数据的持久化，双发都有自己的侧重点，工作量上有私心。
三、组织结构问题
康威定律
第一定律： Communication dictates design （组织沟通方式会通过系统设计表达出来）
第二定律： There is never enough time to do something right, but there is always enough time to do it over （时间再多一件事情也不可能做得美，但总有时间做完一件事情）
第三定律 ： There is a homomorphism from the linear graph of a system to the linear graph of its design organization （线型系统和线型组织架构间有潜在的异质同态特性）
第四定律： The structures of large systems tend to disintegrate during development, qualitatively more so than with small systems （大的系统组织总是比小系统更倾向于分解）
康威定律说明以下几点
四、部署及监控运维
前后端分离后，拆分的服务会带来线上部署以及如何监控运维的复杂性。
总体来说，前后分离所带来的好处还是更明显的。一个成熟的前后端分离的团队，文档化约定，前后端职责分离、接口约定都是做得比较好的
前后端分离交互
新开一个项目,对最近学的vue进行一个总结,这段时间把前后端通信做掉.
请求工具: postman
这里顺便做了个模块化,把通用工具集放common模块中.但是这里有个问题,其实我自己研究的时候没搞懂
整流程逻辑:接收登录参数,判断登录账号密码是否正确,正确的话,生成token,存到redis, 然后返回登录逻辑
postman测试通过,token逻辑也十分简单,就是个密码md5+时间戳再md5
这里并没有设计前后端通信的加密逻辑,基本都是post铭文传输,后续看有没有时间做吧
开发阶段, 跨域问题我用的后端支持
省的前端做转发devserver那种
只有这个方法才能在打成jar包的时候访问文件,另外一个方法是不可以的
后端目前简单的逻辑都做好了,后面有需要的再提.
开发ide: VSCode(皮肤真香)
vscode写前端真是太香了! 各种插件可以装(想起Xcode逝去的青春, 伤心)
最主要讲的是axios的封装, 之前自己直接用的axios,请求模块基本没有封装,惨不忍睹,后面找了很久才找到个好用的,也学到了很多知识(掘金赛高!)
思想就是请求模块放到vue的原型链上,这样就没有侵入性了
请求的时候,直接调用$api对象进行请求,真的非常舒服,之前我都需要那个引入那个,不过这里是否对内存有影响我就暂时不管啦(promise强无敌)
之前写的这里都是不能看的~
VB.Net 前后端分离怎么实现的
1.一般来说，要实现前后端分离，前端就需要开启一个本地的服务器来运行自己的前端代码，以此来模拟真实的线上环境，并且，也是为了更好的开发。因为你在实际开发中，你不可能要求每一个前端都去搭建一个java(php)环境，并且在java环境下开发，这对于前端来说，学习成本太高了。
?2.但如果本地没有开启服务器的话，不仅无法模拟线上的环境，而且还面临到了跨域的问题，因为你如果写静态的html页面，直接在文件目录下打开的话，你是无法发出ajax请求的(浏览器跨域的限制),因此，你需要在本地运行一个服务器，可是又不想搭建陌生而庞大的java环境，怎么办法呢？nodejs正好解决了这个问题。在我们项目中，我们利用nodejs的express框架来开启一个本地的服务器，然后利用nodejs的一个http-proxy-middleware插件将客户端发往nodejs的请求转发给真正的服务器，让nodejs作为一个中间层。这样，前端就可以无忧无虑的开发了
?3.由于前后端分离后，前端和后台同时开发时，就可能遇到前端已经开发好一个页面了，可是却等待后台API接口的情况。比如说A是负责前端，B是负责后台，A可能用了一周做好了基本的结构，并且需要API接口联调后，才能继续开发，
?4.而此时B却还没有实现好所需要的接口，这种情况，怎么办呢？在我们这个项目里，我们是通过了mock来提供一些假数据，我们先规定好了API接口，设计出了一套API文档，然后我们就可以通过API文档，利用mock来返回一些假数据，这样就可以模拟发送API到接受响应的整一个过程，
?5.因此前端也不需要依赖于后端开发了，可以独立开发，等到后台的API全部设计完之后，就可以比较快速的联调。
前后端分离方案以及技术选型
作者：关开发
一.什么是前后端分离？
理解前后端分离大概可以从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全家桶 （推荐，生态全）
小程序怎么制作前后端分离的分享模块
创建一个前后端分离项目。
1、前端只需要独立编写客户端代码，后端也只需要独立编写服务端代码提供数据接口即可。
2、前端通过Ajax请求来访问后端的数据接口，将Model展示到View中即可。
3、前后端开发者只需要提前约定好接口文档，然后分别独立开发即可，前端可以造假数据进行测试，完全不需要依赖于后端，最后完成前后端集成即可，真正实现了前后端应用的解耦合，极大地提升了开发效率。
4、前端应用，负责数据展示和用户交互。
5、后端应用，负责提供数据处理接口。
