spa

1. 概述 SPA单页web应用,vue就是SPA具体技术 不利于SEO SEO: 搜索引擎优化( 增加收录,提高权重 ) SSR: 服务器端渲染技术 将前端分为客户端和服务器端 服务器端渲染就是让服务器端的代码先执行,就可以提前看到数据 nuxt.js就是基于vue.js的SSR技术 1.1 目录结构 nuxt项目目录结构 nuxt: 编译后目录 assets: 存在需要便已处理css,js等资源 components: 组件目录 layouts: 布局目录 pages: 所有组件存放目录 plugins: 插件目录 static: 静态资源目录(js/css/img等) store: vuex数据 nux.config.js: 核心配置文件 package.json: vue项目打包文件 2. 路由 2.1 概述 nuxt.js会自动根据目录结构生成路由 2.2 基本路由 pages文件夹下的每一个文件都对应一个路径 文件位置: pages/user/login.vue 对应路径: /user/login 存在默认文件index.vue 文件位置: pages/user/index.vue 对应路径: /user/ 或 /user 2.3动态路由 使用 下划线_ 表示 动态文件名或目录名 目录结构 访问路径 自动生成路由路径 获得参数 /user/_id.vue /user

阿里妹导读： DataWorks是阿里巴巴自主研发，支撑阿里巴巴经济体99%数据业务建设和治理，每天数万名数据开发和算法开发工程师在使用。 从2010年起步到目前的版本，经历了多次技术变革和架构升级，也遗留了大量的历史包袱。技术的创新和业务的发展，相辅相成但也互为掣肘。存在需求接入慢，代码牵一发而动全身，环境复杂等问题，沉疴已久。历次迭代均未从根基上升级DataWorks，仅仅是一些性能提升、工程结构的优化，减少了重复代码等，并未促成根本性的技术革命。 本文将探讨如何通过当前大热的微服务架构，来改变DataWorks平台的现实问题，从繁杂的工程中探索出一条切实可行的技术架构变革之路 一、痛点 让我们先来谈谈DataWorks当前遇到了哪些痛点，这些痛点是倒逼着我们进行技术变革的源动力。 1.1 沉重的历史包袱 首先要提的就是历史原因遗留的各种问题，DataWorks历史上多个版本同步开发，前后端技术栈多次变革，应用一旦上线就很难废弃，一个对外暴露的api，很可能是5年前开发的，但依然有业务在依赖，通常情况下连这些古老业务的负责人都找不到了。当我们的服务正常运行的时候，无人搭理，一旦下线，则可能不知道从哪儿跳出几个用户前来投诉。页面上的功能同样如此，有时候只是过去不知道哪位同学开发中引入的一个bug，但也因为我们的用户基数庞大，而变成了真理

背景 前后端分离已成为互联网项目开发的业界标准使用方式，通过nginx+tomcat的方式（也可以中间加一个nodejs）有效的进行解耦，并且前后端分离会为以后的大型分布式架构、弹性计算架构、微服务架构、多端化服务（多种客户端，例如：浏览器，车载终端，安卓，IOS等等）打下坚实的基础。这个步骤是系统架构从猿进化成人的必经之路。 核心思想是前端HTML页面通过AJAX调用后端的RESTFUL API接口并使用JSON数据进行交互。 Web服务器：一般指像Nginx，Apache这类的服务器，他们一般只能解析静态资源； 应用服务器：一般指像Tomcat，Jetty，Resin这类的服务器可以解析动态资源也可以解析静态资源，但解析静态资源的能力没有web服务器好； 一般都是只有web服务器才能被外网访问，应用服务器只能内网访问。 以前的Java Web项目大多数都是Java程序员又当爹又当妈，又搞前端，又搞后端。随着时代的发展，渐渐的许多大中小公司开始把前后端的界限分的越来越明确，前端工程师只管前端的事情，后端工程师只管后端的事情。正所谓术业有专攻，一个人如果什么都会，那么他毕竟什么都不精。大中型公司需要专业人才，小公司需要全才，但是对于个人职业发展来说，前后端需要分离。 2、未分离时代（各种耦合） 早期主要使用MVC框架，Jsp+Servlet的结构图如下：

网关（Gateway），简单地说就是请求的入口。如果你接触过微服务，应该经常听到“网关”这个词。 虽然 API 网关并不是微服务所独有的，但它的流行是在微服务兴起之后才开始的。那么到底什么是 API 网关呢？ 基本概念 API 网关是位于客户端和它所依赖的服务之间的一层。有时称为“反向代理”，它们充当从客户端到其服务的单一入口点。 API 网关就像一座大楼的服务台：转接电话，访客登记，快递收发等。 如果你曾经用过第三方 API，你可能就是在跟网关通信，而网关又与服务的内部API 通信。 网关的好处后面会讨论，主要是让服务提供方向外部公开 API 的一部分，并集中处理版本管理、安全、本地化等工作。 API 网关最常见的用途是请求路由。大致过程如下： 客户端向网关发起请求 网关处理这些请求并转发到相关服务 服务向网关发送响应 网关处理响应并发送到客户端 这里的 客户端 可以是各种身份。上面流程提到的原始实现中，客户端是 API 的消费者，但是 API 网关也可以向客户端暴露内部 API。对许多 web 应用来说，客户端就是单页应用（SPA），但也可以是web应用的后端服务器、手机原生应用，甚至是智能电视、媒体播放器和 IoT 设备等。 服务 通常是你的应用控制的内部服务，比如数据库或微服务。网关也可以位于客户端和第三方 API 之间。这样你的用户就可以用统一的方式访问第三方数据了。

在Android native编写代码时，会经常接触到sp、wp，sp并不是smart pointer的意思，而是strong point；wp就是weak pointer。这两个概念比较像JAVA中的强弱引用，使用sp和wp可以让编程人员不需要再关系内存的释放问题，防止内存泄露。下面先来看它们的类关系图： 要实现内存的自动释放，sp、wp必须结合RefBase这个类来使用，在Android中，大多数类的最上层基类都是RefBase类。我们举个简单的例子，然后顺着这个例子来分析RefBase、sp和wp四种不同的应用，并介绍其实现。 class A : public RefBase { } 上面定义一个类A，继承与RefBase，下面我们首先来看RefBases的构造函数： RefBase::RefBase() : mRefs(new weakref_impl(this)) { } weakref_impl(RefBase* base) : mStrong(INITIAL_STRONG_VALUE) , mWeak(0) , mBase(base) , mFlags(0) { } 在RefBase中，首先构造weakref_impl对象，在weakref_impl对mStong和mWeak进行强弱引用计数赋初始值，INITIAL_STRONG_VALUE是0X10000000

SPA:概念 spa指的是single page application 是一种特殊的 Web 应用 ，就是只有一张Web页面的应用， 它将所有的活动局限于一个Web页面中， 仅在该Web页面初始化时加载相应的HTML、JavaScript 和 CSS。一旦页面加载完成了，SPA不会因为用户的操作而进行页面的重新加载或跳转。取而代之的是利用 JavaScript 动态的变换HTML的内容，从而实现UI与用户的交互。由于避免了页面的重新加载，SPA 可以提供较为流畅的用户体验。但是 ，对单页应用来说模块化的开发和设计显得相当重要。 优点： 1. 良好的交互体验，不刷新，减少 请求 数据ajax异步获取 页面流程；用户体验好、快，内容的改变不需要重新加载整个页面 前端进行的是局部的渲染，避免了不必要的跳转和重复的渲染 2.前后端分离，前端负责view，后端负责model，各司其职； 架构清晰 3.减轻服务端压力 服务器只需要提供数据，不需要管前端的展示逻辑和页面合成，提高了 性能 SPA应用中服务器可以先将一份包含静态资源（HTML CSS JS等）的静荷数据（payload）发送给客户端，之后客户端只需要获取渲染页面或视图数据即可， 4.共用一套后端程序代码，设配多端 不用修改后端程序代码就可以同时适配用于web界面、手机、平板等多种客户端；无需考虑兼容 5.可以缓存较多数据

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> [TOC] 一、静态应用部署 官方文档： Nuxt.js 可依据路由配置将应用静态化，使得我们可以将应用部署至任何一个静态站点主机服务商。 可利用下面的命令生成应用的静态目录和文件： npm run generate 这个命令会创建一个 dist 文件夹，所有静态化后的资源文件均在其中。 如果你的项目需要用到 动态路由 ，请移步 generate配置API 了解如何让 Nuxt.js 生成此类动态路由的静态文件。 注意：使用 nuxt generate 静态化应用的时候, 传给 asyncData() 和 fetch() 方法的 上下文对象 不会包含 req 和 res 两个属性。 二、单页面应用程序部署 (SPA) nuxt generate 在 build/generate 时间内仍然需要SSR引擎，同时具有预渲染所有页面的优势，并具有较高的SEO优化和页面加载能力。 内容在构建时生成。例如，我们不能将它用于内容依赖于用户身份验证或实时API的应用程序（至少对于第一次加载）。 SPA应用的想法很简单！ 使用时启用SPA模式 mode: 'spa' 或 --spa ，并且我们运行打包，生成在导报后自动启动，生成包含常见的meta和资源链接，但不包含页面内容。 因此，对于SPA部署，您必须执行以下操作： 将

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 本问题仅限于vue单页应用开发时的讨论。 1、不带参数的网页，如：http://xxx.com/#/CS350001/pray/buddha，分享后打开的网址, 会变成这样：http://xxx.com/?from=singlemessage&isappinstalled=0#/CS350001/pray/buddha，多了一串字符 ?from=singlemessage&isappinstalled=0，这不影响，再打开这个链接并分享，还是正常的。 2、带参数的网页，如：http://xxx.com/#/pray/videoDetail?orderId=64，分享后无法显示自定义的分享内容，这是因为url在传递给后台时带有?等特殊字符，直接传会导致验签失败，所以需要url encode下，总结如下代码： let url = window.location.href; this.$axios({ method:"get", url:'/wx/jssdk/config?url='+(url.indexOf('/?') == '-1'?url:encodeURIComponent(url)), }).then(function (response) {}) 其中/wx/jssdk/config是我后台接口地址

说起前端框架，我个人主张有框架不如无框架，这个观点要先从框架和库的区别说起。 　　我所理解的库，解决的是代码或是模块级别的复用或者对复杂度的封装问题;而框架，更多的是对模式级别的复用和对程序组织的规范，这里的模式是指比如 MVC，为了实现 M 和 V 的解耦，通过 IOC 或是 PubSub 等手段，把丑陋的耦合由经常变化的业务代码转移到不经常变化的框架内部消化。 　　对于前端来说，在 WebApp 概念兴起前，很少能看到所谓的框架，更多的是类似于 jQuery 、YUI 的库，因为前端的一路下来的发展历程和开发方式的特殊性决定了很难有什么通用的模式能满足多样化前端的开发需要。如果一定要说，也就是近些年伴随着 SPA(Single-page application)概念兴起而出现的所谓前端 MVC 的一系列衍生模式，但是即便如此，光靠一个框架还是解决不了什么问题。 　　这里要重点说一下 SPA 这个随着 AJAX 技术火起来的概念，SPA 的好处有哪些相信不用多说，网上一搜一大堆，接近原生 应用 的表现、和 HTML5 技术发展方向向契合等等。SPA 的出现让前端变得越来越重，代码组织、逻辑解耦等后端常常面对的问题也开始在前端出现，人们也开始在前端引入 MVC 去应对这样一些问题，确实很有成效。但是前端变重所面临的问题就仅仅是 JavaScript 层面的 MVC 能解决的吗？ 　

SPA一般只一个web页面，通过ajax，router等技术实现局部刷新，不会随着用户操作而出现重新加载页面或者页面跳转的功能，所有的用户操作都在一个页面实现。 组件化：UI组件和非UI组件 　　传统的ui层：UI和逻辑混在一起，比如往往会在远程请求的回调中更改DOM 　　分层带来的优势：每层的职责更专一，可以对其作单元测试的覆盖，以保证其质量 代码隔离： 　　由于SPA把各种子功能的js代码聚集到一个作用域，因此代码的隔离和模块化很重要 代码合并和加载 　　由于SPA界面基本都是动态生成的，所以不用担心文件加载从而阻塞渲染 路由和状态的管理 　　比如说我们有一个功能，经历过多次导航菜单的点击，才呈现出来。如果用户想要把这个功能地址分享给别人，他怎么才能做到呢？ 　　具体做法就是把产品功能划分为若干状态，每个状态映射到相应的路由，然后通过pushState这样的机制，动态解析路由，有了路由之后，SPA就可以前进后退 缓存和本地存储 服务器通信 　　webSocket实时通讯方式 内存管理 　　传统的web页面一般不需要考虑内存管理，因为用户的停留时间相对少，即使出现内存泄露，可能很快的被刷新页面之类的咋偶哦冲掉。但SPA不会这样，因此我们对DOM操作、网路链接等要格外小心 特点：一个页面集成多种功能，不会随着用户的操作而重新加载页面或者进行页面的跳转，而是局部动态的变换HTML内容