本文僅代表作者個人觀點，來聽聽一個前端程序員的YY衡奥。
新一期的技術(shù)雷達有點出乎意料爹袁，使用new標(biāo)簽的框架、工具矮固、技術(shù)失息、語言等等超過了一半——Vue.js、ES2017上榜档址，Three.js憑著VR的火又上榜了盹兢，還有熟悉的Electron，以及微前端的概念守伸。
讓我們先看看一些技術(shù)亮點绎秒。
前端在可見的未來
在那篇《最流行的編程語言JavaScript能做什么？》的文章里尼摹，我們看到了JavaScript在各個領(lǐng)域的應(yīng)用替裆。在這一期里校辩，仍然有很多亮點（new）：
Vue.js，如果你在使用Vue.js辆童，那么你應(yīng)該更加自信了宜咒，現(xiàn)在它已經(jīng)被列入評估期。Vue.js是一個簡單易上手的框架把鉴，并且相當(dāng)?shù)妮p量故黑，在最近的這段時間里，它發(fā)揮的相當(dāng)?shù)某錾?/p>
可惜庭砍，筆者現(xiàn)在在用Angular.js 和 Angular 2场晶，畢竟我現(xiàn)在的所做的事情是開發(fā)混合應(yīng)用。不過相信在半年后怠缸，Angular 2 和 Ionic 2是會上榜的诗轻。
Ember.js，我現(xiàn)在對這個框架還缺乏深入的了解揭北，而且還沒有證據(jù)表明它會在國內(nèi)火起來扳炬。
ECMAScript 2017，盡管我現(xiàn)在已經(jīng)傾向于使用TypeScript搔体，不過ES2017還是會用到的恨樟，只是我覺得Babel對我來說就是個坑。
Electron疚俱，我在很多場合中都使用過這個框架劝术，從NodeWebkit開始寫編輯器，再到用Electron完成Growth 1.0的桌面版呆奕。
Physical Web养晋，現(xiàn)在我們可以通過藍牙低功耗技術(shù)在瀏覽器上控制真實世界。
不過與此相比梁钾，我更看好 Progressive Web App绳泉，畢竟他可以讓W(xué)eb應(yīng)用接觸到更多的底層API，而不是局限于藍牙陈轿，還可以是Push Notification等等圈纺。
Three.js秦忿，它上榜的原因是WebVR的流行麦射。這一點可以從我去年寫的那篇《Oculus + Node.js + Three.js 打造VR世界》中可以看到一些趨勢。這些就和現(xiàn)在的單頁面應(yīng)用一樣灯谣，雖然運行起來不是那么流暢潜秋，但還是行得通。因而在可見的未來使用Web技術(shù)來開發(fā)VR也有一點苗頭胎许，未來瀏覽器上應(yīng)該是可以運行編譯過后的代碼峻呛，而不是在運行時罗售。
WebRTC，它可以讓我們在瀏覽器端實現(xiàn)實時視頻聊天钩述。第一次接觸到這個視頻流技術(shù)是在兩年多以前寨躁，上一次接觸則是在半年多以前使用WebRTC + Oculus，你可以在我博客的那篇《JavaScript在VR世界的應(yīng)用》中了解到更多的詳細信息牙勘。當(dāng)然如雷達所說职恳，WebRTC將會形成未來在Web上進行AR/VR協(xié)作的基礎(chǔ)。
接著再讓我們看看一些架構(gòu)上的變化吧方面。
前端引起的架構(gòu)變化
在過去的兩三年里放钦，前端火得一塌糊涂——對于后端程序員來說，這有點winter is coming 的感覺恭金。我在那篇《前端演進史》對前端的演進做了相當(dāng)多的介紹操禀，并在《后臺即服務(wù)演進史》里對"后臺即服務(wù)"開了個頭，在這篇文章里讓我們根據(jù)《技術(shù)雷達》來繼續(xù)補幾刀横腿。
我們可以看到颓屑，很多中大型團隊已經(jīng)分解為前端和后臺兩個小組，溝通可以通過接口蔑水、契約等方式來進行邢锯。但是這一點兒也不精益，溝通在這時仍然是一個問題搀别，讓我有點懷念起之前前丹擎、后端都做的項目了——自己可以創(chuàng)建自己想要的接口。
不過歇父，這意味著前端和后臺在技術(shù)選型上更加獨立了蒂培。
臃腫的前端——微前端
在上一個項目里，我們一步步地將一個有近10年歷史的系統(tǒng)替換掉榜苫。起初這是一個傳統(tǒng)的Spring + JSP網(wǎng)站，然后我們用JSP創(chuàng)建了JSON API垂睬，后來創(chuàng)建了一個新的API來服務(wù)移動應(yīng)用和單頁面應(yīng)用媳荒，再后來這個API被拆分成了幾個API。我們的后臺已經(jīng)從一個單體應(yīng)用變成了一個微服務(wù)架構(gòu)的應(yīng)用驹饺，但是這一點并沒有在前端上應(yīng)用——前端應(yīng)用正在變得難以維護钳枕。
因此在這一期的雷達里，你可以看到微前端的概念（micro frontends）赏壹。這也是在上一個項目里鱼炒，我們嘗試做的一部分，遺憾的是并沒有完全成功實施蝌借。這是一個搜索類型的網(wǎng)站昔瞧，網(wǎng)站的首頁承擔(dān)著大部分的訪問量指蚁，而詳情頁的主要流量來源則是搜索引擎。我們在首頁上使用jQuery + Require.js技術(shù)棧自晰，而在其他頁面（搜索結(jié)果頁 + 詳情頁）使用 React.js凝化，我們在最初的時候考慮過將詳情頁靜態(tài)化——因為需要SEO的緣故，這樣可以讓我們降低SEO帶來的復(fù)雜度酬荞。
后來缘圈，我也在我的博客上解耦了兩部分，為了更快的訪問首頁——將首頁獨立出來袜蚕，不使用JS糟把，直接使用Pure.css來擔(dān)重任；在其他頁面里使用Material Design Lite作為UI部分牲剃。
有一點值得考慮的是：對于微服務(wù)架構(gòu)來說遣疯，在一個系統(tǒng)的不同部分使用不同的技術(shù)棧是一種不錯的體驗；而對于一個前端團隊來說凿傅，在同一個系統(tǒng)中使用不同的技術(shù)棧就不是一種不錯的體驗缠犀。
API設(shè)計——應(yīng)該變得簡單
如我們所見的Spring Boot已經(jīng)變成推薦采用的程度了，按雷達上的習(xí)慣用語：“我們已經(jīng)在多個項目上使用這個框架”——反正我最近的項目都是用這個框架聪舒。如果你考慮使用 Java辨液，那么一定不要錯過這個框架，以及使用這個框架來實施前后端分享箱残。
對于大部分不需要考慮SEO的應(yīng)用來說滔迈，將后臺變成一系列RESTful的API并不是一件復(fù)雜的事，但是在后臺API上的設(shè)計就變成一件麻煩的事被辑。因此盡管在實踐的過程中有契約作為保證燎悍，但是不一定是可靠的。作為一個前端程序來說盼理，我們在調(diào)用后臺API的過程中谈山，總會遇到這樣、那樣的問題宏怔。除此奏路，還有接口不好用的問題——“要是你可以在這里使用超媒體API，那么我的代碼就會更加簡單了”臊诊。
因此在 API 設(shè)計上鸽粉，雷達上給出了兩個不錯的案例：
強化后臺查詢
代表例子就是Facebook的GraphQL，它是在Facebook內(nèi)部應(yīng)用多年的一套數(shù)據(jù)查詢語言和 runtime妨猩。原本為了請求一個用戶及其好友信息潜叛，需要發(fā)起多個API請求』喟現(xiàn)在壶硅，我們只需要在客戶端拼裝好對應(yīng)的Query語句威兜，在這個語句里將大部分需要查詢的東西寫好，即 JSON格式的數(shù)據(jù)庐椒，然后發(fā)給服務(wù)端來處理椒舵。而在我們客戶端上，我們所獲取到的結(jié)果都是我們所需要的约谈，不需要再做特殊處理了笔宿。
這一切，看上去很美好——除了棱诱，在客戶端上拼查詢語句泼橘。
過去，我們使用搜索引擎來搜索數(shù)據(jù)迈勋，就需要在前端拼好對應(yīng)的Query炬灭，再傳給后臺API，由后臺API返回我們需要的結(jié)果靡菇。在這個過程里重归，我們在Query做一些對應(yīng)的數(shù)據(jù)處理。
反正厦凤，他們都是使用查詢語言來搜索結(jié)果鼻吮。如果你考慮使用QL的話，不妨做一層Wrapper较鼓，以后好做遷移椎木。
前后端同時優(yōu)化
Netflix在這樣復(fù)雜的API請求下，創(chuàng)建了自己的庫Falcor——它可以從多個數(shù)據(jù)源獲取數(shù)據(jù)博烂，并在服務(wù)端上匯總成一個JSON model拓哺；在客戶端上，請求時我們只需要加上對應(yīng)的參數(shù)即可——可以將多個請求合并到一起脖母，也可以只針對某一個部分發(fā)出請求士鸥。這樣可以降低發(fā)出多個請求所帶來的復(fù)雜度。
我想谆级，一種最實用的做法：就是將一些更新頻率較低的API合并成一個大的API(大部分人都會這樣做吧)烤礁。
簡化的后臺——無服務(wù)器架構(gòu)
除了上面的這些內(nèi)容，后臺還有一些東西蠻好玩的肥照，其中一個就是Serverless架構(gòu)脚仔，即無服務(wù)器架構(gòu)。不過舆绎，這種架構(gòu)目前在國內(nèi)運行起來還是有點難度的鲤脏，缺少一系列的配套措施。如在這期的雷達上，Auth0可以為我們提供一個授權(quán)服務(wù)猎醇，以及AWS Lambda可以直接使用 AWS系列云服務(wù)來對數(shù)據(jù)進行處理窥突。
關(guān)于這期技術(shù)雷達我就不多說了，讀者可以自己去看硫嘶。點擊原文就可以獲取最新一期ThoughtWorks技術(shù)雷達阻问。
那么未來，你想玩哪種技術(shù)沦疾。
更多精彩洞見称近，請關(guān)注微信公眾號：ThoughtWorks
