前端工程师如何应对,揭秘react生态体系

 科技资讯     |      2020-05-07 04:18

图片 1

技术栈示意

前言

react 的生态体系比较庞大,它在web端,移动端,服务器端,VR领域都有涉及。

react可以说是目前为止最热门,生态最完善,应用范围最广的前端框架。react结合它的整个生态,它可以横跨web端,移动端,服务器端,乃至VR领域。

可以毫不夸张地说,react已不单纯是一个框架,而是一个行业解决方案。

下面就来说说 react庞大生态体系的构成。

阿里妹导读:尽管大部分前端的工作并不涉及server,但最近半年serverless这个词汇以及其引发的热烈的讨论,深深触动了阿里巴巴高级前端技术专家伐薪。作为接触前端十余载的老开发,伐薪认为serverless可能会是接下来引起前端领域革命性变化的技术之一。

H5

html的最新标准,IE8以上的浏览器支持,这个新标准增加了很多特定的标签。

一,react生态之——web端

react本身是面向web端的,它很轻便灵活,只是MVC架构中的view(视图)层。由于只是view层,所以它需要配合生态体系中的其他框架或模块来使用。

今天,伐薪将为大家梳理serverless的历史发展进程以及对前端的影响,希望对前端工程师有所启发。

CS3

CSS的新标准,增加的流式布局,dispplay:flex, 区别于以前的箱式布局方式display:box, 这种技术非常适合制作屏幕可以根据大小自由伸缩的需求

react的web生态构成
  • ** 1,路由 **
    react的路由解决方案有多个,这里只提最常用也最优秀,以及最为推荐的两个,分别是react-routerreact-router-redux。

  • ** 2,状态管理器 **
    react只是UI层,对于如何管理应用的状态,facebook提出了flux架构,而基于这一架构,react生态陆续出现了reduxrefluxjsmobx、react-redux 等一系列状态管理框架。

其中reduxmobx是无疑是最受欢迎的两个。但它们的应用场景则大不相同。
Mobx 适合做一些简单的应用,原型实验,适合小的团队使用。Mobx 的优点是响应状态的变化。

redux适合复杂的应用,大团队,需求变化多。它的优点是响应动作和事件。
redux不仅应用于react,也可以应用于angular,vue等框架,只是redux和react配合使用最为契合。

另外国内蚂蚁金服前端团队基于redux, react-router打造了另一个前端框架——dva
dva简单来讲是对redux方案的集成与拓展,它突破框架的本身,形成一套略为完整的前端架构,处理了很多包括项目构建,异步处理、统一请求、统一错误处理等一系列诸多问题。

如果你选择redux方案,那么建议直接使用dva

  • ** 3,UI库 **
    和vue,angular相比,react的UI库无疑是最为丰富的,且十分优秀。目前react的UI库有将近二十多个,这里主要列举最为优秀的几个。

首先国外的有material-ui、react-toolbox。它们都基于谷歌的material设计理念,因此界面非常精美,尤其适用于web开发。

其次是国内蚂蚁金服开源的ant design,以及百分点公司开源的bfd-ui。这两个都是企业级的UI库,提供的组件极其丰富,此外逻辑交互也处理得非常好,基本不需要你操作过多的业务逻辑即可完成开发。

而在这众多的UI库中,表现最为出色的莫过于蚂蚁金服开源的ant design。

  • ** 4, 一些工具 **
    ** Immutable **
    immutable-js是facebook推出的完全独立的一个js库,侧重函数式编程中不可变数据结构,使用Immutable可使你的react应用性能上会有很大的提升。

** draft-js——基于react的编辑器语言 **
draft-js 是由facebook开源的编辑器语言。它提供了众多API可用于定制化开发你想要的react编辑器。

** css-modules ——css模块化解决方案**
css-modules不是为react而生的,它是css模块化的一种解决方案,但它和react配合使用非常的契合。
css的发展,已从最原始的css,到后来的less/sass,再到postcss,以及css in js,再到css-modules。无一不是向着模块化进发,甚至于有没有可能发展到组件化style,还有待实践和考察。

** React Devtools——react调试工具 **
react-devtools是facebook推出的一款调试工具。可有助于提高你的react应用开发效率。

** Babel——es6/7 **
开发react应用,推荐使用babel搭建es6/7开发环境。这样你就可以尽情地使用高逼格兼高效率、高体验的es6/7语法了。
无论是react,还是redux,还是Immutable等等,甚至是不相关的rx.js,都强调函数式编程。
说句题外话,整个react体系,都在强调js,甚至连css(css-modules)、html(jsx)都融入了js处理,所以提高你的js驾驭能力可使你在前端路上不会迷失。

** TypeScript **
TypeScript是微软开源的JavaScript 的一个超集,主要提供了类型系统和对 ES6 的支持。而TypeScript也因此成为了angular的一个制胜关键点。
那react能否使用呢?当然是可以的。
蚂蚁金服所开源的React UI库ant design就是使用TypeScript来开发的。由此可知其强大。
顺便提供几个TypeScript的学习教程: 官方文档、简易中文版、中文版教程

  • ** 5,react项目构建 **
    前端构建工具有很多种,比如最为流行的webpack、百度开源的fis3、以及 gulp。而开发react应用,推荐使用强大的webpack做项目构建。这也是官方的推荐。

图片 2

React + Flux

React是前端JS开发框架,前端的开发已经和桌面程序前端开发的理念很接近了,基本概念就是数据和html的页面元素的绑定以及同步,react认为双向数据同步会造成混乱,即页面元素变化,数据模型也跟着变,因此他的实现的单向的数据同步,另外react的一个牛气的机制就是虚拟DOM,类似于java的虚拟机,用虚拟DOM可以解决前端浏览器的品牌和版本兼容性问题。
Flux是辅助实现单数据流编程的框架。

react的web技术栈的选择

通过上面可以了解到,react的web技术栈非常的丰富,搭配不同的路由、状态管理器、UI库,构建工具等不同的组合,可整理出二十几种技术栈方案。

下面来说说根据不同应用场景,最为推荐的几种技术栈方案。

** 1,开发后台应用 **

  • react+react-router+mobx+webpack+bfd-ui/ant design (三星半)
  • react+react-router+redux+webpack+bfd-ui (三星)
  • react+react-router+redux+webpack+ant design (四星)
  • react+dva+bfd-ui (四星半)
  • react+dva+ant design (五星)

** 2,开发前台web应用 **

  • react+dva+bfd-ui/ant design (四星)
  • react+dva+material-ui/react-toolbox (四星半)

上图是serverless 这个词最近5年在 google 的搜索趋势,可以看到最近半年已经达到巅峰。

Npm,Nodejs, Webpack

以前的js开发都是开发单独的.js文件,然后html页面引用多个js文件来实现,随着前端类库的增多,js文件的庞大,html引入js文件也变成了一个负担,开发环境管理js库也变得复杂;

因此google推迟Npm作为js的包管理器,安装npm就需要安装nodejs;
基于nodejs可以实现用js编写server端脚本,node js server充当web服务器;
基于npm, webpack是一个打包工具,可以把使用到的类库打包为一个js文件供html引用。

二,react生态之——移动端

react不仅在web端占据主流的位置,同时在移动端表现尤为突出。这里不得不提到RN,也就是react-native

react-native是目前最优秀的非原生开发移动框架,一处开发,多端使用。同时具有出色的性能,支持热更新等超强的优势,使得react-native顿时站在风口浪尖。

vue和angular在移动端同样有建树,分别是weex和ionic+cordova。然其综合性价比仍不如react-native

而最近facebook推出React Fiber 架构,使用Fiber对react核心算法进行重写,届时RN的性能将会再次直线式的上升,向原生步步紧逼。

开发RN应用所用的技术栈与web端大致相同,同样需要结合redux,react-router, dva, mobx等周边生态来使用。

另外也有一些适合RN的移动端UI库。比如ant design的mobile版——ant-design-mobile,以及响应式的material-ui

历史上前端领域的重要技术革命

ES6

javascript的2015的最新标准,有很多新的利于工程实践的语法支持。但是部分浏览器是不支持的。所以需要Babel作为转译工具;

三,react生态之——服务器端

react不仅涉足web端,移动端,同样在服务器端也有非常好的涉猎。
react在服务器端的实践有两部分,一个是服务器端渲染,另一个就是强大的graphql

Ajax 的诞生

Babel

把ES6的JavaScript语法转译为浏览器兼容性更强的ES5版本;

react服务器端渲染

react提供了两个API来实现服务器端渲染,分别是——renderToString 和 renderToStaticMarkup。

而对于react服务器端渲染实践最为出色的莫过于next.js。这是一个基于react可实现服务器和浏览器都能渲染的框架。

除了next.js,还有一个比较出色的案例 ——react-server。它同样实现 了React 框架在服务器和浏览器中进行快速渲染和无缝切换。

除了以上这两个服务器端渲染的框架外,还有一些比较好用的实现react服务器端渲染模块,比如如express-react-views,react-view等等。

先来回顾一下前端技术领域的重要历史节点,第一个节点是2005年,google的Jesse James Garrett 发表了一篇文章——《Ajax:Web应用程序的新方法》,首次发布了Ajax 这个新的词汇(准确说并不是新的技术,只是新的词汇),当时我还在读大二,虽然ajax不是什么新的技术,只是对XmlHttpRequest等技术的包装,但是这个技术被google宣传之后成为全球web开发的标杆,间接促进了富客户端应用和单页应用的流行,这些应用大都具备丝滑般的体验,并一直伴随着web 2.0的发展,ajax的深入人心,使得前端js的工作更加复杂和重要,专业分工越来越细,间接促进了专职的前端开发人员这一角色诞生,在此之前,web开发并不区分服务端和浏览器端的工作,因此ajax是前端领域的第一次重要事件。

GraphQL——超前,另类的API

graphql是facebook开源的应用层查询语言。它很超前,时髦,可适用于包括nodejs,java,php等绝大都数后台语言。

它超前到什么程度?举个例子,我们只需要使用一个 GraphQL 的接口,即可满足一个简单博客网站的所有需求。有没有觉得很神奇?准确地说graphql是为接替RESTful而生的。

RESTful是当下非常流行的,主流的一套前后端API交互设计规范。几乎绝大都数互联网公司都在使用。那么为什么还需要graphql来接替RESTful呢?

其实,现在谈graphql替代RESTful还为时尚早,因为graphql还有很多问题需要解决,而即使真到了那一天,RESTful也仍有一定的市场空间。

RESTful本身存在的一些缺点和不足,比如,当需求或数据发生变化时,需要建立新的接口来适应变化,而不断添加的接口,会造成服务器代码的不断增长,即使通过增加接口版本,也并不能够完全限制服务器代码的增长。另外不断地增加接口,意味着将带来更多的开发工作,而且每个接口基本都无法复用等一系列问题。

graphql就是为解决这些问题而生的。
下面来看看一个简单的GraphQL请求:

{
  latestPost {
    _id,
    title,
    content,
    author {
      name
    },
    comments {
      content,
      author {
        name
      }
    }
  }
}

而请求的结果是这样:

{
  "data": {
    "latestPost": {
      "_id": "03390abb5570ce03ae524397d215713b",
      "title": "New Feature: Tracking Error Status with Kadira",
      "content": "Here is a common feedback we received from our users ...",
      "author": {
        "name": "Pahan Sarathchandra"
      },
      "comments": [
        {
          "content": "This is a very good blog post",
          "author": {
            "name": "Arunoda Susiripala"
          }
        },
        {
          "content": "Keep up the good work",
          "author": {
            "name": "Kasun Indi"
          }
        }
      ]
    }
  }
}

很明显,GraphQL是从客户端业务维度出发的,当客户端需要某些字段的数据时,只需要发出这些字段的GraphQL请求即可。按需索取,可复用,可定制化,灵活性很强。

这会不会就是未来前后端交互的一种趋势呢?我们拭目以待。

图片 3

Relay 和 Apollo Client

上面已经有讲到, relay是facebook出品的一个前端数据框架。

我们使用graphql,为什么需要用到 relay呢?

首先,graphql是在后端实现的,准确地说是在后端搭起一个graphql服务器,它不会主动推送数据给客户端,也无法像RESTful那样由客户端发起一个ajax请求来请求后端的RESTful API。graphql需要在客户端有一样东西能与它进行交互,但不是ajax或者fetch,而是经过封装的如relay或apollo等能够与graphql服务器进行交互的前端数据框架。

relay就是这样应运而生。但实践中会发现使用relay来配合graphql使用通常会遇到很多坑,relay操作起来并没有想象中的简单,除了比较复杂以外,它同时存在很多局限性。

于是,不得不提到apollo。它是一个全功能的 GraphQL 客户端,用于 React 、Angular 等的交互,允许你轻松通过 GraphQL 获取数据并构建 UI 组件。

使用apollo+graphql,它并没有relay那样的繁琐,也没有relay那样的局限性。无疑和graphql是最配的。

关于graphql的体验,很多用过的人表示,爱不释手。

下面是一些关于graphql的比较好的文章和资料:

  • graphql官方文档
  • Apollo Client官方文档
  • relay官方文档
  • graphql学习资料收集
  • Node.js 服务端实践之 GraphQL 初探
  • 深入理解 GraphQL

Nodejs 对前端规范化和工程化的促进

四,react生态之——VR领域

目前,VR(虚拟现实)是科技界的新生事物,也是一大革命,在未来,VR将很大程度地改变人类的生活方式。

试想一下,VR将为你呈现一个虚拟现实世界,你将可以使用VR身临其境般地玩游戏,看新闻,购物,社交娱乐,看世界名景等等,这将是一个全新的世界。

那么,react难道有涉足VR领域吗?

是的,没错。

react不仅走在web端、移动端以及服务器端的前沿,还很超前地在VR领域布了个局——react-vr

接下来对前端变化最大的一个里程碑事件是2009年诞生的 nodejs(包括common js及npm)的出现和流行,它对前端领域的重要意义并不仅仅是让前端可以快速用js写server那么简单,个人认为它最大的贡献反而是commonjs、npm以及其便捷开发体验促进的前端工程化,它使得前端开始从刀耕火种的和传统软件工程格格不入的部署方式,发展为接近传统企业应用的研发模式,在此之前,前端开发在资源引用、依赖管理以及模块规范上缺乏有效的工具和标准,但是nodejs流行以后,基于commonjs的模块及npm的包部署和依赖管理成为主流(类似java的maven体系),并诞生了多种基于nodejs开发的cli工具辅助前端开发(如grunt、gulp),npm目前是全球最大的包管理仓库,并且成为前端项目的包依赖管理事实标准。而webpack的出现,又使得前端代码的部署更加简便,让前端可以以类似java jar包的形式发布应用,而不管项目中是何种类型的资源。

react-vr——webvr框架

不得不说facebook是一家技术含量很高,着眼长远的科技巨头。

下面主要讲讲webVR。

webVR是VR技术在浏览器的实现。

目前VR的技术实现方案仍在起草阶段,但有些技术方案几乎是铁定的。比如作为如底层的OpenGL、WebGL、three.js

而目前就有一些基于底层技术开发出来的webVR框架,比如——react-vraframe

aframe是由mozilla于15年开源的,目前已更新到0.5.0版本。

react-vr 于2017年4月18日举行的facebook F8开发者大会上正式发布,并在github放出了第一个开源版本—— react-vr。并号称——使用react即可创造出惊人的360°景象和VR内容。

react始终是走在web巅峰的路上。

以下是参考资料:

  • aframe官方文档
  • react-vr官方文档
  • three.js官方文档

图片 4

五,react生态之——全平台的reactxp

reactxp是微软Skype团队开源的一个基于react和react native开发的全平台框架,它不仅支持Android和iOS,还支持web和windows,目前还尚不支持mac。是眼下跨平台最广的一个框架,准确来说是一个js库。
reactxp的出现算是微软在wp跨平台计划失败后的又一次跨平台实践。是否也预示着前端终将会实现大一统呢?
拭目以待。
reactxp目前还很嫩,还有很多问题需要解决,比如它的某些API只有ios能用,并不能做到全兼容,像浏览器一样存在兼容性问题,这只是其一。
reactxp真正要火起来还有很长的路要走,但不妨碍我们可以继续关注它。也许它能超越RN,成为最前沿的跨平台应用框架也说不定。

React 的组件化及vdom理念

总结

react早已不是一个单纯的库,结合它庞大的生态体系,它已然发展成为一个行业解决方案,它所渗透的领域非常广,也非常的前沿,很具有代表性。

通过本文,相信你对react的生态体系有了一个直观的了解。

本文的部分链接需要翻墙,如果你不懂如何翻墙,可以试试开眼插件、蓝灯,或者购买一个国外的主机,自己搭一个vpn服务器。比如有一年免费期的亚马逊ec2。
关于如何搭建vpn服务器,你可以跑这个脚本,过程很简单。—— setup-ipsec-vpn

我的github: https://github.com/sessionboy (欢迎来点星星)
知乎专栏: https://zhuanlan.zhihu.com/sessionboy
简书ID: sessionboy
个人站点: http://sinn.boyagirl.com/

第三个革命性事件是2013年开始出现的react,尽管web components标准在此之前早已发布,但是真正让组件化理念深入人心并且应用最广的库是react,它还至少有两点特性足以让它成为历史上最具前瞻性的前端库,第一个特性是vdom的出现,在此之前,所有的ui库,都直接与dom关联,但是react在UI创建与渲染引擎之间,增加了一个中间层——vdom(一个使用轻量级json描写UI结构的协议),除了改善了其本身的dom diff性能之外,还有一个重大意义就是UI的编写与渲染开始分离,一次编写,多端渲染的UI得以实现,这个多端包括server端、移动端、pc端以及其他需要展示UI的设备,之后的react native以及weex都是这一分层思想的受益者。

除了vdom之外,react还有一个重要的理念非常超前,即UI是一个函数,函数输入一个state,一定返回确定的视图,在此之前,大部分框架和库,都会把UI分离成一个html片段(通常支持模板写法以渲染数据),一个为该html片段绑定事件的js,尽管这样比较好理解,但是react对UI这种抽象却反映了UI的实际本质,并且这种函数式理念,在后面可以看到,将与faas及serverless技术产生美妙的碰撞。

图片 5

react 的诞生对此后,甚至此前的框架和库都产生了深远的影响,包括不限于angular和vue都陆续采纳了它很多技术思想,并且成为前端开发领域目前已经趋于稳定的屈指可数的几个技术选型之一。

再来总结一下,ajax使得前端的角色逐渐分离出来,nodejs促进了前端的开发模式向传统编程语言靠近,react的出现,基本结束了后端常常对前端”技术变化快“的吐槽,至此,前端的技术体系逐步成熟和标准化。

图片 6

serverless 理念与前端的关系

那么为什么说下一次对前端技术领域有较大影响的理念是serverless呢,事实上,尽管serverless这个词汇由亚马逊提出来还不到几年,但是这个理念并不是什么爆炸性的新理念,在早期,cdn还不普及的时候,web工程师会把js资源和视图文件(可能是静态也可能是动态的)传到服务器,那个时候前端是需要关心服务器的,但是cdn及回源策略的普及,工程及搭建系统的大规模使用,使得前端可以快速把一个js或者静态文件扔到cdn节点,通过回源机制(cdn回源到一个动态服务),半动态的视图层渲染也成为可能,在这整个过程,前端开发无需关心任何服务器的知识,也不知道cdn有多少节点,如何做负载均衡,做gslb的,也不需要知道qps多少,一个cdn可以放各种业务各种开发的资源,可以说cdn是serverless理念的的先行者。

回到应用部署,在前几年nodejs刚流行的时期,已有开发者意识到应用与机器的部署与运维成本对业务方会是个问题,出现了一些容器化的思想,比如cbu在15年出的naga,在这个naga容器里,业务逻辑是一个个插件,容器负责请求的路由分发,负载及稳定性管理,业务方只需要编写并上传最直接的业务代码即可,对业务方来说是实现了serverless的理念,因为naga的维护者帮你解决了部署及运维的问题。

再说对前端息息相关的页面搭建系统以及bff层,无论是各种搭建系统(如斑马、积木盒子、TMS),还是基于graphQl的平台,还是通过web ide快速编写api gateway的产品——如cbu的mbox,都让业务开发只关心业务逻辑,无需关心部署运维知识,它们一定程度上体现了serverless的理念。

serverless 将对前端的影响

综上所述,前端早已与serverless产生了联系,但是很多人还没感知,接下来,serverless显示化地爆发将给前端带来更为深远的影响,主要体现在三个方面。

前端将会重新回归到web应用工程师这一职能

在最前面说了,前端是社会分工的细化,大约起源于2007年左右,在此之前是没有专门的前端开发角色的,通常称作web工程师或网站工程师,早期的网页大都是服务器渲染,使用asp、php、jsp等server page技术,js仅仅是web工程师需要掌握的小小技能之一,但是随着web 2.0及互联网、移动互联网、电子商务的发展,需要专门的人专注于编写具备很好兼容性和体验的UI,因此逐渐产生了专注于浏览器及移动端的前端工程师。

但是前端技术领域逐渐趋于稳定,伴随着十几年的发展,各种开箱即用的库、垂直方案以及工程手段唾手可得,甚至目前出现了一些辅助工具可以把设计师的视觉稿生成UI代码,前端可以安心并且以非常低的成本编写UI和业务逻辑,而不用耗费大量精力在选型、造轮、还原视觉、处理兼容性、性能优化、调试和部署上,这种情况,前后端工种分离造成的协同成本反而放大了,因为在前后端角色分离的情况下,后端往往还会充当bff层的角色,比如为前端表现层封装各种api gateway,经常出现相互等待、联调协议的情况,而且bff层通常只是一些数据的加工,其他的角色经过短期的培训可以快速上手,因此前端一直在尝试接入到server端的bff层。

在15年前端开始推广使用nodejs来部署应用,阿里内外也出现了不少nodejs的框架,如业界的express,在生产环境,包括给买家、商家以及内部人员使用的系统,有不少使用了nodejs,但是到今年2019年,再来回顾一下,发现这个数字并没有超出预期。

造成这一现象的原因,个人认为归根到底还是因为分工太细导致的前端对服务器知识的缺乏,nodejs本身的定位是服务器技术,本质上在服务器要面对的问题与java无异,现有的前端jd招聘的人才,鲜有能在服务器上工作游刃有余的人,除非专门招的nodejs人才,server服务的长期运行会暴露很多问题,比如接口很慢,进程core,cpu飙升,内存泄漏等,另外负载均衡、扩缩容,高并低延等知识,大部分前端都是没有这些经验的。

云计算的本质就是要让业务开发专注于业务逻辑,业务之下的硬件及软件设施都是按需采买,开箱即用,而serverless理念及相关技术,将使得开发人员不再需要关心应用及机器的问题,甚至连流量能不能撑住也不用关心了,它能自动扩缩容,因此,未来web开发人员的运维成本会大幅降低,前端也可介入到bff层的开发,而后端可以聚焦于数据处理、业务逻辑与算法。

这一变革符合研发效能提升的背景,未来的云设施将会做得非常厚,非常专业、稳定,而前台开发人员可以快速地,最低成本地在云设施上建立业务逻辑,前端和服务器的前端(对整个请求链路来说,前端是相对的,只要离客户请求更近的角色都可以称自己为前端),分工将没那么明确,以前的浏览器端的前端,将逐步承担一部分服务器端接入层以及bff层的工作,返璞归真,回到历史上曾经的web开发工程师角色,这是对前端最大的一个变革。

当然,serverless技术让前端回归到传统的web层,不代表前端不用掌握服务器知识了,掌握操作系统内核及网络编程知识仍有助于你编写高性能、高可用的业务应用。

图片 7

实时SSR将成为展示端UI的主要开发模式

最早的web开发,其实处理UI都是以服务器渲染为主,比如perl、php等动态网页技术,但是在前端逐渐成为一个工种开始负责了绝大部分UI开发,并且技术域逐渐缩小到客户端范围之后,网页静态化以及客户端的渲染逐渐成为主流。

但是这种模式对用户体验肯定是有问题的,导致了较多的白屏时间,而由于新的前端库如react和vue在vdom这层的抽象,服务器渲染的技术成本更低,因此SSR在最近几年,又逐步开始流行。

但是SSR的难点恰恰是前面说的,服务器端人才的匮乏,虽然nodejs和vdom的普及提升了SSR的实施效率,但由于服务器知识的缺乏,通常只有少部分具备综合知识的前端会深入的实践这一领域。

serverless技术的普及将把这个问题消除掉,借助于serverless技术,前端可以快速搭建一个ssr的场景,在服务器取数,在服务器渲染,直出html给到客户端,而不用关心这个渲染服务能否扛得住流量,会不会挂掉,这些事情云设施供应商会去解决。

在前面说过,react有一个核心理念就是把UI看成函数,如果说一个页面是多个组件组成的,那一个组件是函数,我们可以把一个页面看成是多个函数的组合,不同函数的组合,组合成不同的导购场景,如果把一个函数看成一个微服务,一个场景就是微服务的聚合,这恰恰是faas的理念。

通过serverless低成本地实时ssr,可以让客户体验更好,借助算法和大数据,还可以快速实现UI的千人n面,构建真正的导购大脑。

图片 8

基于场景的云开发将成为主流开发模式

在提到serverless技术的时候,有一个关联的领域不得不提,那就是web ide,很多互联网大型企业把一个web ide当成了云的基础设施并且大力投资,这是为何?个人认为有两个原因。

第一个是因为serverless目前在业界使用以垂直场景为主,他们有一个共同点,就是代码足够标准、规范,场景较为垂直,代码复杂度不是很大,而且借助web ide可以快速地与云平台结合,做到一键发布,因此这种场景,是比较适合轻量的在线编码到部署全链路打通的。

另一个原因是,目前所有的云设施解决的是业务运行问题,但是软件开发有一个非常大但是大部分人可能会忽略的痛点,那就是环境问题,相信很多人都有那种clone别人的项目但是废了九牛二虎之力都无法启动的问题,因为要装各种环境啊?另外就是和别人联调的时候,是不是因为各种环境部署缺失的问题,联调效率很低?

借助容器如docker等技术,软件的运行及调试环境,可以快速地移植给别人复用,而目前基于js的代码编辑器已经非常强大,vscode editor就是基于js编写并且沉淀出一个库 Monaco Editor,因此可以说,大部分认为web ide可能在语法提示、智能感知上比不上本地ide的想法是过时了。

图片 9

同时web ide可以快速地与平台集成,深入定制,打通业务平台,一键部署,极大地提升研发效率。

web ide还能解决跨地办公的问题,因为解决了环境准备这一老大难问题,你可以在家里,在公司,甚至在火车上,快速编写并交付代码。

因此未来的paas平台,都将关联一个深度定制的web ide,需要编写业务逻辑时,一个连接跳转到web ide即可编码,完全无需关心本地环境问题,做到真正的envless。比如你要开发一个TMS模块,那么点击”新建“,跳到了web ide,代码会帮你初始化好,点击运行,会在云端启动服务器运行该组件,编写好之后,一键即可发布到TMS。

对于各种faas、api gateway系统以及其他云服务,都会一样,web ide将成为企业云化的基础设施。尽管阿里云目前还未发布媲美cloud9以及coding.net的web ide,但是很欣喜地看到集团内部已经涌现出一些优秀的产品,如aone的ide,以及数据平台的app studio,其体验已经接近业界顶级水准。

结语

在云计算领域,serverless将会掀起一场革命,即使看起来与这一领域关联不大的前端,也会经受即ajax、nodejs以及react之后的又一重大变革,你做好应对了吗?

本文作者:伐薪

上一篇:没有了 下一篇:没有了