分类: 技术雷达

本文仅代表作者个人观点,来听听一个前端程序员的YY。

新一期的技术雷达有点出乎意料,使用new标签的框架、工具、技术、语言等等超过了一半——Vue.js、ES2017上榜,Three.js凭着VR的火又上榜了,还有熟悉的Electron,以及微前端的概念。

让我们先看看一些技术亮点。

前端在可见的未来

在那篇《最流行的编程语言JavaScript能做什么?》的文章里,我们看到了JavaScript在各个领域的应用。在这一期里,仍然有很多亮点(new):

Vue.js

Vue.js,如果你在使用Vue.js,那么你应该更加自信了,现在它已经被列入评估期。Vue.js是一个简单易上手的框架,并且相当的轻量,在最近的这段时间里,它发挥的相当的出色。

可惜,笔者现在在用Angular.js 和 Angular 2,毕竟我现在的所做的事情是开发混合应用。不过相信在半年后,Angular 2 和 Ionic 2是会上榜的。

Ember.js,我现在对这个框架还缺乏深入的了解,而且还没有证据表明它会在国内火起来。

ECMAScript 2017,尽管我现在已经倾向于使用TypeScript,不过ES2017还是会用到的,只是我觉得Babel对我来说就是个坑。

PWA

Electron,我在很多场合中都使用过这个框架,从NodeWebkit开始写编辑器,再到用Electron完成Growth 1.0的桌面版。

Physical Web,现在我们可以通过蓝牙低功耗技术在浏览器上控制真实世界。

不过与此相比,我更看好 Progressive Web App,毕竟他可以让Web应用接触到更多的底层API,而不是局限于蓝牙,还可以是Push Notification等等。

VR

Three.js,它上榜的原因是WebVR的流行。这一点可以从我去年写的那篇《Oculus + Node.js + Three.js 打造VR世界》中可以看到一些趋势。这些就和现在的单页面应用一样,虽然运行起来不是那么流畅,但还是行得通。因而在可见的未来使用Web技术来开发VR也有一点苗头,未来浏览器上应该是可以运行编译过后的代码,而不是在运行时。

WebRTC,它可以让我们在浏览器端实现实时视频聊天。第一次接触到这个视频流技术是在两年多以前,上一次接触则是在半年多以前使用WebRTC + Oculus,你可以在我博客的那篇《JavaScript在VR世界的应用》中了解到更多的详细信息。当然如雷达所说,WebRTC将会形成未来在Web上进行AR/VR协作的基础。

接着再让我们看看一些架构上的变化吧。

前端引起的架构变化

在过去的两三年里,前端火得一塌糊涂——对于后端程序员来说,这有点winter is coming 的感觉。我在那篇《前端演进史》对前端的演进做了相当多的介绍,并在《后台即服务演进史》里对”后台即服务”开了个头,在这篇文章里让我们根据《技术雷达》来继续补几刀。

前后端分离

我们可以看到,很多中大型团队已经分解为前端和后台两个小组,沟通可以通过接口、契约等方式来进行。但是这一点儿也不精益,沟通在这时仍然是一个问题,让我有点怀念起之前前、后端都做的项目了——自己可以创建自己想要的接口。

不过,这意味着前端和后台在技术选型上更加独立了。

臃肿的前端——微前端

前端单体应用

在上一个项目里,我们一步步地将一个有近10年历史的系统替换掉。起初这是一个传统的Spring + JSP网站,然后我们用JSP创建了JSON API,后来创建了一个新的API来服务移动应用和单页面应用,再后来这个API被拆分成了几个API。我们的后台已经从一个单体应用变成了一个微服务架构的应用,但是这一点并没有在前端上应用——前端应用正在变得难以维护。

因此在这一期的雷达里,你可以看到微前端的概念(micro frontends)。这也是在上一个项目里,我们尝试做的一部分,遗憾的是并没有完全成功实施。这是一个搜索类型的网站,网站的首页承担着大部分的访问量,而详情页的主要流量来源则是搜索引擎。我们在首页上使用jQuery + Require.js技术栈,而在其他页面(搜索结果页 + 详情页)使用 React.js,我们在最初的时候考虑过将详情页静态化——因为需要SEO的缘故,这样可以让我们降低SEO带来的复杂度。

MicroServices

后来,我也在我的博客上解耦了两部分,为了更快的访问首页——将首页独立出来,不使用JS,直接使用Pure.css来担重任;在其他页面里使用Material Design Lite作为UI部分。

有一点值得考虑的是:对于微服务架构来说,在一个系统的不同部分使用不同的技术栈是一种不错的体验;而对于一个前端团队来说,在同一个系统中使用不同的技术栈就不是一种不错的体验。

API设计——应该变得简单

Backend

如我们所见的Spring Boot已经变成推荐采用的程度了,按雷达上的习惯用语:“我们已经在多个项目上使用这个框架”——反正我最近的项目都是用这个框架。如果你考虑使用 Java,那么一定不要错过这个框架,以及使用这个框架来实施前后端分享。

对于大部分不需要考虑SEO的应用来说,将后台变成一系列RESTful的API并不是一件复杂的事,但是在后台API上的设计就变成一件麻烦的事。因此尽管在实践的过程中有契约作为保证,但是不一定是可靠的。作为一个前端程序来说,我们在调用后台API的过程中,总会遇到这样、那样的问题。除此,还有接口不好用的问题——“要是你可以在这里使用超媒体API,那么我的代码就会更加简单了”。

因此在 API 设计上,雷达上给出了两个不错的案例:

强化后台查询

GraphQL

代表例子就是Facebook的GraphQL,它是在Facebook内部应用多年的一套数据查询语言和 runtime。原本为了请求一个用户及其好友信息,需要发起多个API请求。现在,我们只需要在客户端拼装好对应的Query语句,在这个语句里将大部分需要查询的东西写好,即 JSON格式的数据,然后发给服务端来处理。而在我们客户端上,我们所获取到的结果都是我们所需要的,不需要再做特殊处理了。

这一切,看上去很美好——除了,在客户端上拼查询语句。

过去,我们使用搜索引擎来搜索数据,就需要在前端拼好对应的Query,再传给后台API,由后台API返回我们需要的结果。在这个过程里,我们在Query做一些对应的数据处理。

反正,他们都是使用查询语言来搜索结果。如果你考虑使用QL的话,不妨做一层Wrapper,以后好做迁移。

前后端同时优化

Falcor

Netflix在这样复杂的API请求下,创建了自己的库Falcor——它可以从多个数据源获取数据,并在服务端上汇总成一个JSON model;在客户端上,请求时我们只需要加上对应的参数即可——可以将多个请求合并到一起,也可以只针对某一个部分发出请求。这样可以降低发出多个请求所带来的复杂度。

我想,一种最实用的做法:就是将一些更新频率较低的API合并成一个大的API(大部分人都会这样做吧)。

简化的后台——无服务器架构

ServerLess

除了上面的这些内容,后台还有一些东西蛮好玩的,其中一个就是Serverless架构,即无服务器架构。不过,这种架构目前在国内运行起来还是有点难度的,缺少一系列的配套措施。如在这期的雷达上,Auth0可以为我们提供一个授权服务,以及AWS Lambda可以直接使用 AWS系列云服务来对数据进行处理。

关于这期技术雷达我就不多说了,读者可以自己去看。点击原文就可以获取最新一期ThoughtWorks技术雷达。

那么未来,你想玩哪种技术。

Share

发表评论

评论