開源、全站、低代碼項目 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 的開發實踐