摘要:年底了,開源一套我們的大前端架構,小伙伴們都用得很爽的。聽說的人明年會發財文檔是一套正式上線的大前端解決方案。是一套前端端彼此相親相愛不分離,你中有我,我中有你的大前端解決方案。
年底了,開源一套我們的大前端架構aotoo-hub,小伙伴們都用得很爽的。
GITHUB -- 聽說star的人明年會發財
文檔
aotoo-hub是一套正式上線的大前端解決方案。迭代的這2年多的時間,從webpack-1熬到了webpack-4,從純前端腳手架到融合node端的整體方案,從繁復到精簡,重構的次數不要太多。簡單、易用、易部署的一體化大前端開發體驗是aotoo-hub始終的追求,我們不是在重構,就是在重構的路上(保持一致性)。
aotoo-hub是一套前端、node端彼此相親相愛不分離,你中有我,我中有你的大前端解決方案。前端負責靜態資源編譯與分享,node端負責服務、路由與渲染,模板則起到橋接兩端的作用(結構、樣式、渲染),最終http服務將渲染完成的模板投送到客戶端瀏覽器上。
完整的大前端方案需要解決前端、node兩端各自的開發、部署難的問題,并且需要將兩端融合為一套有機的整體,同時還能兼顧到工程化實現。aotoo-hub開發迭代的過程中我們始終秉持著下面這些原則
通用性盡量多的支持多種開源框架,使我們能夠為不同業務選擇合適的開源框架。aotoo-hub現在支持react,vue,小程序(alpha),未來也許能夠加入app的相關框架,比如RN或者FLUTTER?
融合性前端與node的有機融合不止是一種更好的體驗,同時前端、node端能夠共享靜態資源,部署同構組件,簡化resful的路由等,一體化的設計使得項目的開發、部署、維護都變得簡單且易于維護。也許你會用到egg,nest等node框架作為后端支撐,maybe更好的方案是java, go, php等的框架。
易用性aotoo-cli是專門為aotoo-hub打造的一套命令工具,使得aotoo-hub更容易上手了,還是寫寫code演示一下
啟動默認項目
# 安裝aotoo-cli $ npm install -g aotoo-cli # aotoo -V檢驗是否安裝成功 # 新建workspace $ aotoo init oneWorkspace #創建目錄oneWorkspace,并初始化項目環境 # 啟動默認項目 $ cd oneWorkspace $ aotoo dev
新建項目
# 安裝aotoo-cli $ npm install -g aotoo-cli # aotoo -V檢驗是否安裝成功 # 新建workspace $ aotoo init oneWorkspace #創建目錄oneWorkspace,并初始化項目環境 # 新建項目 $ cd oneWorkspace $ aotoo create newProject # 創建一個項目,名稱為newProject # 啟動項目開發版本 $ aotoo dev newProject # then open browse http://localhost:3000 # 編譯項目 $ aotoo build newProject # 靜態資源會cdn化 # 啟動生產項目 $ aotoo build newProject $ aotoo start newProject # 使用node啟動 $ pm2 start index.js -- --start newProject # 使用pm2啟動生產項目
對吧,命令行應該不算復雜。好了,這里大概對aotoo-hub進行了一些介紹,接著和大家說說創建項目的流程及初始化項目的文件構成
準備 支撐系統mac osx
linux
windows,主要是/和的問題
node-gyp
node-pre-gyp
$ npm install -g node-gyp $ npm install -g node-pre-gyp一、新建workspace
新建workspace其實就是一個準備編譯環境的過程,我們會準備編譯文件,項目目錄,項目配置文件
# 新建命名空間 $ aotoo init wp-1
aotoo.config.jsaotoo-hub的配置文件,可以在這里設置項目初始目錄,版本號等等配置信息,配置內容大致如下
const path = require("path") const pakg = require("./package.json") const ROOT = __dirname const version = pakg.version module.exports = { // 版本信息,由package.json的version來指定 // 默認情況下,所有項目產出的版本號都會依據這個version值 // 版本信息會被用于生成dist下的版本目錄 version: version, // node的環境變量NODE_ENV mode: process.env.NODE_ENV, // workspace的根目錄地址 // 會用在aotoo安裝插件時,及node端(目錄層級很深)掉用 ROOT: ROOT, // 所有項目的原始根目錄 src : path.join(__dirname, "src"), // 配置默認項目信息 // 小程序項目必須使用這個配置 // 當我們不使用start, name等命令選項時,aotoo-hub會查找該屬性下startup為true的項目,并嘗試啟動 // 當我們配置好默認項目后,命令行可以簡化projectName apps: [ { // 項目名稱,與src項目項目目錄一致 // 任何項目都必須有自己唯一的名稱 name: "aotooSample", // 是否啟動該項目 startup: true, // 指定項目源源目錄 src: path.join(ROOT, "src/aotooSample"), // 默認靜態資源輸出地址為 src/dist // 這里可以手動指定希望輸出的目錄 // dist // 指定項目端口地址 // 指定項目端口,可為null,系統自動分配端口地址 port: 8400 } ] }
build目錄包含所有的編譯文件
src目錄src是默認aotoo-hub的源目錄,所有新建項目都會在次目錄下生成項目文件夾
aotooSmple目錄是我們的一個demo項目,是aotoo-hub的默認項目,以供參考
# 啟動默認項目,開發模式 $ aotoo dev二、新建項目
下面我們開始新建一個項目
$ cd wp-1 $ aotoo create newProject項目初始目錄 完整項目目錄
初始目錄是一個精簡版的項目,保留了最基礎的文件及目錄,完整目錄如下
wp-1 └── src └── newProject ├── component //組件目錄 │ └── ...... ├── ssr/sync // 同構模塊目錄 │ └── ...... ├── dist // 靜態文件輸出目錄 │ └── ...... ├── js // 前端業務js目錄 │ └── index.js ├── css // 前端業務css目錄 │ └── index.styl ├── html // 前端業務模板目錄,一般的模板都會自動生成,如需要自定義幕版,則根據同名規則自定義生成相關模板 │ └── index.html └── server // node端的源碼目錄 │── pages // koa2的control層目錄 │ └── index.js └── plugins // 自定義插件目錄,適用于node端 └── ......
注意所有以下劃線開始的文件、目錄在編譯時會被忽略,如_abc/或者_abc.js
configs目錄項目環境配置文件夾,存放多個環境配置文件,如測試1,測試2,生產等環境配置,所有環境配置在應用是會與公共的default.js配置文件合并
js目錄存放公共JS,業務JS目錄
vendors目錄
公共JS,公共CSS,自動被模板引入。我們將公共JS分為兩個部分vendors.js,common.js,公共CSS只有一個common.css
vendors.js: 主要內容為框架源碼,如react, vue, react-router等
common.js: 根據業務JS由webpack自動生成
common.css: vendors.js中引入的*.styl(aotoo-hub只支持stylus),webpack會將其分離成common樣式,該文件也會被模板自動引入
dist: 編譯生成 dist/**/js/vendors.js
js/*.js
所有的模板,樣式自動生成的依據,因為js目錄下的所有文件都被當成獨立的業務JS文件,會被各個業務頁面自動調用
dist: 編譯生成 dist/**/js/*.js
html目錄
非必要目錄,主動生成,aotoo-hub會自動生成模板文件(依據js/*.js),并包含一個id=root的div。
特殊模板需求,請依照*.js的同名文件新建,如src/../js/abc.js對應src/../html/abc.html
dist: 編譯生成 dist/**/html/*.html
css目錄
非必要目錄,被動生成,aotoo-hub會自動生成樣式文件(依據js/*.js引入的stylus文件)
dist: 編譯生成 dist/**/css/*.css
component目錄
非必要目錄,組件存放目錄,一個別名目錄,我們在node端,前端可以方便引入組件
import someComponent from "compoent/someComponent" ...
sync目錄
非必要目錄,同構業務模塊存放目錄,一個別名目錄,我們在node端,前端可以方便引入組件
import someMoudle from "sync/someMoudle" ...
server
node端服務文件
aotoo-hub的node端基于開源庫aotoo-koa-server實現。
默認新建的項目是一個純前端項目,但某些項目有SEO需求,需要我們啟動node端來渲染頁面
# 帶node端啟動項目 $ aotoo dev newProject --server
新項目有默認的demoindex頁面,新項目的node端會自動幫你把所有的node端需要的環境搭建好,同時創建了pages/index.js這個默認的demoindex頁面
configs.js
這個文件每次啟動時會根據src/newProject/configs/目錄下的環境配置自動創建,因此如果修改配置請移步src/newProject/configs/中
index.js & lib.js
aotoo-hub為你將server環境都配置在lib.js中,如果你需要擴展配置,如使用新的koa2的插件,建議修改index.js文件,參考lib.js的寫法
pages/*.js
這里是node端業務js,與src/js/*.js對應同一個業務,且同名,如src/newProject/js/abc.js => server/pages/abc.js
// server/pages/abc.js // 該文件為koa2框架MVC中的contro層文件 // aotoo-hub接管了渲染方法,因此你只需返回渲染所需的數據部分,oridata /* * * oridata {JSON} 系統傳遞變量,用于渲染模板,需要return oridata * ctx {context} koa2的ctx變量 * * * get: method = GET * post: method = POST * put: method = PUT */ module.exports = function (oridata) { return { get: function name(ctx) { oridata.title = "aotoo-hub 多項目全棧腳手架" oridata.root = "123" ctx.redirect("/docs") // return oridata }, post: function name(ctx) { return oridata } } }
dist
前端靜態資源編譯后的文件存放位置
1.0.3/
版本目錄,根據aotoo.config中的版本信息
* dev/ 該項目處于開發模式,生產模式使用/pro目錄 * html/ html模板編譯輸出目錄 * mapfile.json 資源映射文件三、啟動項目 單項目啟動
# 開發編譯,并啟動前端 $ aotoo dev newProject # 如果需要node端(該命令一次生效,終生有效,且后續啟動時不需要參數 `--server`) # 開發編譯,并啟動Node端 $ aotoo dev newProject --server # 生產編譯 $ aotoo build newProject # 只啟動node端(編譯完成) $ aotoo start newProject # 帶環境編譯或啟動 $ aotoo start newProject --config env_test多項目啟動
生產環境支持多開項目,且會為每個項目自動分配端口(未指定),開發模式則受制于nodemon對多開不友好的功能,會報錯(pm2替代就可以),啟動多開也很簡單,可以參考上面aotoo.config.js的配置,
將startup: false設置為 startup: true就好了,啟動時不用指定項目名稱,如`
aotoo dev,或者指定一組項目名稱,如:aotoo dev --name aaa --name bbb`
今天對aotoo-hub有一個大概的介紹,有問題請提issue,鑒于本人有社交懶癌,問題不一定能及時回答,平時畢竟工作有點多.
文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://m.specialneedsforspecialkids.com/yun/100477.html
摘要:什么是前后分離前后端分離并不是什么新鮮事,到處都是前后端分離的實踐。然而一些歷史項目在從一體化設計轉向前后端分離的架構時,不可避免的會遇到各種各樣的問題。搞了一個前后分離,需要分離部署。 探究 :深入聊聊前后分離架構 前后分離,一直是一個相當泛泛的問題,前后分離到底好不好?沒有絕對的對,沒有絕對的錯,業界就這個問題已經激烈的探討幾年了.出現討論的點在于:分離當然是好的,但是以什么樣的服...
摘要:什么是前后分離前后端分離并不是什么新鮮事,到處都是前后端分離的實踐。然而一些歷史項目在從一體化設計轉向前后端分離的架構時,不可避免的會遇到各種各樣的問題。搞了一個前后分離,需要分離部署。 探究 :深入聊聊前后分離架構 前后分離,一直是一個相當泛泛的問題,前后分離到底好不好?沒有絕對的對,沒有絕對的錯,業界就這個問題已經激烈的探討幾年了.出現討論的點在于:分離當然是好的,但是以什么樣的服...
摘要:什么是前后分離前后端分離并不是什么新鮮事,到處都是前后端分離的實踐。然而一些歷史項目在從一體化設計轉向前后端分離的架構時,不可避免的會遇到各種各樣的問題。搞了一個前后分離,需要分離部署。 探究 :深入聊聊前后分離架構 前后分離,一直是一個相當泛泛的問題,前后分離到底好不好?沒有絕對的對,沒有絕對的錯,業界就這個問題已經激烈的探討幾年了.出現討論的點在于:分離當然是好的,但是以什么樣的服...
摘要:百度云智峰會召開。百度云發布,與百度大腦的最新迭代版本共同構成百度。作為新的增長極,百度云補完了百度長期商業版圖中缺乏的環,與共同構成了百度這座火箭的核心引擎。2018 ABC SUMMIT百度云智峰會召開。百度云發布ABC3.0,與百度大腦、Apollo、DuerOS的最新迭代版本共同構成百度AI3.0。壓軸出場的百度云ABC3.0向人們展現了引領智能變革的雄心。事實上,云計算正成為企業戰...
摘要:第二種則由多個小單元構成,每個小單元都是獨立的服務。微服務架構所依賴的彈性通信輕量等需求容器恰好可以完美提供,因此微服務與容器可以說是完美的一對。談到架構,微服務架構已然是時至今日必聊的一個話題,系統架構的選型與是否轉型,不應該是為了微服務架構而架構,而是源于微服務架構自身是否更適合業務自身的需求,微服務架構的優勢與所要付出的代價是否值得你,去做一次轉變。 ? ?GIStack for M...
閱讀 2071·2023-04-25 22:58
閱讀 1419·2021-09-22 15:20
閱讀 2704·2019-08-30 15:56
閱讀 1996·2019-08-30 15:54
閱讀 2113·2019-08-29 12:31
閱讀 2736·2019-08-26 13:37
閱讀 601·2019-08-26 13:25
閱讀 2103·2019-08-26 11:58