開源低代碼平臺開發實踐一：低代碼開發探討與技術選型

開源、全站、低代碼項目 rxDrag 的前、後端演示終於全都上線了，停下來喘口氣，把開發實踐經過系列文章的方式分享出來，順便整理一下思路。

當決定要作這個低代碼項目的時候，低代碼還不像如今這樣火。

開發過程當中，只是以爲前端後端合起來，有不少冗餘信息，被代碼一遍遍重複表達，是一件很枯燥、無聊的事情。

這些枯燥的重複工做，徹底能夠由機器來作，以便解放出咱們的時間，來作更有價值的工做。

帶着這些有點兒天真的想法，開始了低代碼開發的探索之路。隨着工做愈來愈深刻，接觸到的低代碼領域的人也愈來愈多。慢慢意識到，低代碼火了！

當看到資本們瘋狂的追逐、老闆們天馬行空的幻想、商家們無底線的吹捧、程序員們充滿優越感的鄙視...

不免會思考，本身作低代碼的意義究竟是什麼？爲何要趟這趟渾水？當大潮退去，一地雞毛，一個四十多歲業餘程序員的時光，是否被毫無心義的消耗掉了？

可是，有時候夢想的種子被種下，就很難將其湮滅。可能就是這份執念的驅動，讓本身堅持了一年多，前端後端都嘗試一遍。

最後也想明白了，生命是以死亡爲代價的，全部消失的事物，只要存在過，或多或少就實現了部分自身價值。全部的嘗試，無論成功仍是失敗，都會成爲社會進步的動力。區別是，有的變成了肥料，有的開出了花朵，有的還結出了果實。

管那麼多呢，只要以爲本身作的工做可以幫助某些人，這樣的工做就是有意義的。是否過分被追捧，形形色色的評判又有什麼關係，就算在鬧市裏，也能夠徹底尋一方靜室，作本身喜歡的事情，而後堅持到底！

把本身的開發經驗、心得儘可能多的分享出來，就算項目開不了花、結不出果，那麼充當肥料，也要更有養分一些。

在分享開發經驗以前，先回答一些問題。

低代碼到底有沒有用？

低代碼不是軟件開發方面的銀彈，它解決不了軟件危機，它更像是一個工具，就像近視鏡、助聽器、汽車、輪船等同樣。

這些工具備一個共同的特色，就是對有些人有用，對有些人卻沒用。

低代碼也是這樣的。

做爲一個外貿從業者，見證了這樣一個過程：從用靜態頁面作企業網站，到 wordpress 的蓬勃發展，再到 Shopify 的一統獨立站天下。這個過程裏，看到軟件技術應用徹底普及開來，還有很大的市場空間。有不少對軟件技術不是很熟悉，對軟件有很強烈的使用需求的人，卻不得門而入。

Wordpress 跟 Shopify 只是知足了這部分人的一部分需求，就取得了巨大的成功。低代碼的存在，能夠更好地服務有相似需求的人羣。在這個領域，什麼凡科、美篇、易企秀只是初級的開始，相信會有更多更優秀的應用不斷涌現的。這些應用本質上都是低代碼。

人天生就不肯意作一些重複性枯燥工做，程序員也是。常常見一些優秀程序員，炫耀本身代碼結構多麼優秀，優秀到這樣的程度：本身完成主要架構，重複性代碼交給低端程序員去作。

問題是，誰是低端程序員，誰願意作低端程序員？

這些枯燥的重複性工做，交給機器來作，是更爲明智的選擇。

有條件的公司，根據本身的業務領域，把一些通用的東西抽出來，打造一個專屬本身的低代碼框架，是否是能夠提升本身公司的開發效率？是否是能夠系統的擴展能力？是否是能夠提升爲客戶定製的能力？是否是具有了快速原型化一個願景的能力？

具備這些能力的前提是，願意預先花必定的成本，作一個低代碼平臺。因此低代碼是每個開發者均可以參與的事情，不是大資本的專利。

也但願本身作的rxDrag系列低代碼項目，可以提供一些有價值的借鑑和幫助。若是某些模塊，能被真正應用起來，那麼持續這麼長時間的忙碌也算值了。

低代碼不能作什麼？

不少事情，都是低代碼不能完成的，它不能作的事情太多了，不能送我上下班、不能替我接孩子、不能治療疾病..., 不要去要求它什麼都行，也不要把關注點放在這個方面。

當聚焦在它能作什的麼時候，咱們關注的創造，看到的是客戶。只關注正向東西，會帶來美好人生體驗。

程序員會被淘汰嗎？

低代碼完成的是一些枯燥的，重複性的工做。做爲一個程序員，若是堅持要作這些工做，跟沒有情感的機器搶飯吃，那麼多是要被淘汰的。若是是帶有情感的工做，是不容易被機器取代的。

在Wordpress之前，國內的建站公司遠比如今多，你們收着客戶不菲的價錢，套用着劣質模板，作着充滿濃濃鄉土氣息的企業網站。

直到 Wordpress 出現，國外大量的質優價廉的主題模板經過 Wordpress 生態圈子進入國內，有些作外貿培訓的機構，憑藉教客戶用WordPress建站，年收入達上億元。不少國內建站公司被淘汰。

試問這些被淘汰的公司，輸得心服口服嗎？沒有任何編程經驗的人，通過短短培訓，作出來的網站，秒殺大家收費高昂的鄉土網站，憑什麼不被淘汰？

淘汰，是新事物取代舊事物的過程。一個工種消失，每每會產生更多新的工種。就像馬車車伕消失了，卻出現了各類駕駛員、宇航員。

面對這樣的變化，須要感嘆嗎？須要恐懼嗎？須要譴責嗎？這樣的態度誰會在乎？這些變化誰能阻止？歷史車輪滾滾，時代要淘汰咱們的時候，會跟咱們打招呼嗎？面對這些，咱們除了全力奔跑，還能作些什麼？

技術突飛猛進，愛卻永恆不變。愛、美、創意不只歷來沒有被淘汰，反而愈來愈珍貴。願意相信，真心爲他人着想，用心服務客戶的人，不會被淘汰，只是換個服務客戶的形式而已。

低代碼不是毒瘤，也不是萬能藥，只是一個工具，這個工具既會被好人使用，也會被壞人使用。不要由於壞人在吹捧它，就對它充滿敵意，它是無辜的。也不要由於大資本追捧，而神話它，它只是個工具。

技術棧的選擇歷程

技術棧太多了，不一樣的技術棧，適合不一樣的應用場景。就我的來說，畢竟經驗有限，很難說哪一個更優。

只是分享用過技術的使用體驗，但願能對有些朋友多少能提供一點借鑑意義。

最初從新進入開發領域，是要給公司作個CMS項目，由於看到了PHP在市場上的成功，就選擇了PHP + Laravel，後來瞭解了VUE。在使用VUE的過程裏，很是喜歡組件的概念。就萌生了用VUE+Laravel作一個低代碼平臺的想法。作低代碼平臺夢想的種子，或許就在這個時候已經種下了。

頁面表單輸入的、請求接收到的、跟存到數據庫的每每是一樣的數據，卻要在3個地方處理3遍，添加或者修改一個字段，就要3處代碼所有改一遍。基於對這用冗餘工做的厭惡，當時用PHP作了一個簡易低代碼框架：經過PHP函數構造前端頁面的JSON描述，同時能夠綁定字段數據。前端作了一個VUE渲染引擎，用於渲染後端傳來的JSON。

用這樣的方式，雖然冗餘代碼問題解決了，結構卻不合理。頁面跟業務數據耦合太緊密。

雖然做爲業務程序員，技術水平通常，可是願意折騰，願意分享。疫情期間作了一個小的HMTL可視化編輯的小玩意，無心間居然登上了知乎的熱搜，由此認識了不少朋友。

跟朋友交流多了，不少新的想法跟着進來了，知道能夠把界面的描述不用PHP代碼生成，直接把描述JSON寫在數據庫裏。很是感謝當時提供這個思路的網友「衝動」。

這時候的技術棧是：PHP + Laravel + Vue。設計思路是，經過可視化拖拽的方式構建前端JSON描述，把這些描述存在數據庫裏，作一個專門的渲染引擎，渲染這些界面，並綁定數據。目標是作一個不須要代碼的前端，具體後端怎麼實現，並無考慮太多。

一我的作開源，不可能全部東西都本身作，選一個成熟UI庫是必要的。在還不瞭解什麼事 material design 的狀況下，誤打誤撞選中了 Vuetify。因爲技術的不熟練，接下里在作 Vuetify 的可視化拖拽的過程裏，經歷了曲折的過程。有的坑是由於本身水平太菜，有的坑則是技術棧選擇的問題。

在處理拖拽事件的時候，使用 Vuetify 的方式總感受不是特別天然，總以爲應該有更順暢的方式。不是功能上實現不了，而是總以爲彆扭。另外，對Vue的 slot 也有些使用不習慣。在這樣的狀況下，決定去了解React。

看了一遍 React 文檔，就被折服了。原來十幾年前，只是書本上談論的編程思想，已經被人實踐出來變成了產品。做爲沒有任何約束的自由開發者，已經不可能再回到 Vue 了，註定要在 React 的路上走下去。

既然選中了 React，那麼 TypeScript 順便一塊兒學，也就瓜熟蒂落了。

使用一個陌生的東西，不可能結構設計很合理，給本身定的目標就是先完成功能，而後再重構優化代碼。

邊學習，邊製做，跌跌撞撞完成了初版可視化前端。技術棧是：TypeSctipt + React + Redux + Material ui。

初版完成，就火燒眉毛掛出演示，在幾個論壇發了一下，反響還不錯，雖然本身知道還差不少。接下來將近一年的時間裏，都是不斷重構折騰的過程。

初版跟後端通信的接口是 Web api，用 mockjs 作的演示數據。這時間點，網友「靈活的胖子」給本身推薦了 mobx 跟 GraphQL，做爲一個自由開發者，嘗試幾項新的技術，並非困難的事情。使用 GraphQL 和 mobx 對前端重構，天然而然也就發生了。目前的演示版本，就是基於這兩項技術重構後的版本。

mobx 的優點不言而喻，雖然不少朋友不喜歡，以爲跟 React 的理念不搭，但對我來講不是障礙。mobx是從低代碼界的扛把子項目mendix發展出來的，對於低代碼項目是很是友好的。在使用的過程當中，mobx 用起來仍是很是舒服的。

可是，提及 GraphQL，可就一言難盡了。

後端的抉擇：代碼生成仍是實時運行？

前端完成，後端的實現面臨兩個方向：代碼生成跟實時運行。

代碼生成技術已經發展多年，實現起來最爲簡單，卻鮮有成功案例。大廠們開發出來的基於代碼生成的IDE，大都化成了時代灰塵，被人遺忘在某些角落裏。

作一個精悍的、開箱即用的實時後端，無疑是本身最但願完成的做品。

但是，現有的開源庫，除了 hasura，跟 GraphQL 相關的，大都基於代碼生成。它們能夠成爲開發者的優秀工具，卻很難成爲低代碼平臺的首選。

做爲團隊只有一我的的業餘愛好者，只能融入一個開源生態，是沒有精力什麼都本身作的。目前，幾乎沒有什麼時間跟精力，開發一個跟 Hasure 相似的 GraphQL 服務端。只能暫時放棄 GraphQL，改用傳統 Web API。

到目前爲止後端的實現爲 JSON API + 指令的方式。演示已經能夠運行，文檔也已初步完成。

本身內心很清楚，就這樣放棄 GraphQL，很不甘心，說不定之後的某一天，還會再回來。

後端技術棧的選擇

後端技術，一直是傾向於 PHP 生態的。使用 GraphQL 的時候，就計劃好了，Laravel + Lighthouse。

鍾情於PHP的緣由有三個：

1. 前 Web 時代 PHP 的成功；
2. 本身知識的匱乏，不瞭解太多新的技術，畢竟離開行業過久了；
3. 解釋語言對熱拔插友好，適合低代碼項目。

在使用 Lighthouse 過程裏，感受上總有些不暢，最後仍是被朋友勸退了，放棄 PHP，在 Java 跟 TypeScript 兩個裏面選一個。

選擇Java，是不須要有任何顧慮的，畢竟成熟又成功。可是，仍是想嘗試一下 TypeScript，希它可以帶來更多的可能。

rxDrag的目標是中小型項目，相信 TypeScript 足以勝任。目標執行語言是js，是一種解釋語言，熱加載友好，可使用JS生態圈的東西。

使用一段時間以後，發現 TypeScript 的開發效率要比 PHP 高好多，一句話：TypeScript真香。

到目前爲止，後端技術棧：TypeScript，nestjs，TypeORM。

前端技術棧：TypeScript，React，Mobx，Material ui。

先後端都有演示能夠運行。

對技術棧選擇的思考

前一段時間，讀高瓴資本創始人張磊的《價值》（應該是他說的，不是特別肯定），他表達了這樣一個觀點，基於經濟學的比較優點原理，接入全球統一的大市場，是一個國家發展的必要條件，中國近40年的快速發展，也是受益於改革開放，接入全球市場。

一樣的道理，能夠拿到技術棧的選擇上來。選擇技術棧的時候，儘量接入大的生態圈子，短時間商業項目可能並看不出什麼優點，長期來看，接入更大生態的項目會走的更遠。

低代碼平臺的重心在哪裏

開發 rxDrag 的前端項目DragIt，大約用了1年的時間，後端項目 rxModels 大約2個月。先後端完成之後，最深入的感悟就是，低代碼項目的重心應該放在後端。

這想法與隨處可見的拖拽低代碼，顯得有點格格不入。

只須要靜靜坐下來，回顧一下這些年的發展，會發現後端的發展速度是要比前端慢的。Java全家桶發展了近20年，總體思路變化不大，前端倒是飛速變化着。這意味着，同時開發出前端跟後端兩個項目，後端生命週期大機率會長於前端。

無論前端跟後端，圍繞的核心都是數據，數據管好了，能夠衍生不少前端應用。我的建議，把管理重點放在靠近數據的後端部分。

rxDrag項目裏，它的後端部分 rxModels 也是整個項目的核心。

rxDrag低代碼平臺

rxDrag力圖構建一個全棧低代碼生態圈，它的核心就是後端的對象管理模塊 rxModels。目前包含這些內容：

• rxModels 是一個對象管理服務器，經過繪製ER圖，就能夠實時構建一個能夠運行的後端。提供通用JSON接口，用於操做服務端數據，而且能夠經過指令擴展接口。內置了基於角色的細粒度權限管理。項目地址：https://github.com/rxdrag/rx-models
• rxmodles-swr 一套React鉤子，輔助跟服務端 rxModels 通訊。項目地址：https://github.com/rxdrag/rxmodels-swr
• DragIt 可視化低代碼前端。項目地址：https://github.com/rxdrag/dragit
• 還有一個從 DragIt 分離出來的，不依賴具體 UI 庫的拖拽框架，如今還麼想好叫什麼名字。

下一篇文章內容

分享 rxDrag 後端項目 rxModes 的開發實踐