開源低程式碼平臺開發實踐一：低程式碼開發探討與技術選型
開源、全站、低程式碼專案 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的原因有三個：
- 前 Web 時代 PHP 的成功；
- 自己知識的匱乏，不瞭解太多新的技術，畢竟離開行業太久了；
- 解釋語言對熱拔插友好，適合低程式碼專案。
在使用 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 的開發實踐