今天花時間在了解後端的架構，由於目前規劃會用js和go進行不同服務的撰寫，所以展開專案目錄如何架構的了解。在多篇文章章的閱讀後，js端有差不多的想法了，但go端目錄還存在不太了解的部份。
整個目錄會以Monorepo的方式存放，但跨了二個不同的語言，而不同的語言都有自己的目錄和建置規劃。而Nodejs裡，要做monorepo，現階段最推薦的就是lernajs。官方的文件很清楚，目錄架構是
這樣的目錄結構其實在nodejs的開發中一直是很自然地一種分切方式，只是lerna又在這樣的基礎上加了相依性的管理等，故目錄結構本身很好理解，用或不用lerna只是在開發上有package引用時是否可以直覺的做到。所以對於nodejs這沒有太大的問題。
而在go這部份，一直在go module出現前go的專案都是統一放置在gopath下，也就是不論什麼專案，都要放在一起。而go module出來後，目錄擺放位置才變得比較有彈性。且在命名上和目錄結構上，也沒有統一的規範，故這塊沒有標準的情況下，就變得要找很多看似正確的範例專案來看才能於比較歸納後得到一個較能被接受的結構。
這三個目錄命名方式，這篇文章有些著墨，但在Go Project Structure Best Practices裡提到terrfaform的目錄結構榜樣，確也整個結構調整過了，也就是之前的best practices典範不再。也利用以下的文章了解到各式各樣的結構規劃、命名
不過具體要怎麼建構還在思考中。
除了目錄規劃外，另一個部份就是在於後端建置要如何進行。前端的Unity，利用Google Cloud Build進行處理後推到Unity Cloud Build，這樣的流程是確定的。但回看後端的建置，就算nodejs不需要進行編譯，也可能不像前端一樣要進行webpack打包的動作，但仍需要某些處理，至少也還是有可能會轉譯成es5等規範。更不用說go，它是需要進行編譯的。
利用Google Cloud Build的情況下，若是能在加入某種建置上的輔助，應該就是我所需要的。而在monorepo關鍵字的領導下，看到了Bazel。
Bazel的建置概念也很單純，概念上就是在專案的最上層加入
二個檔，並在其中填入設定值後就可以利用bazel指令，在更下層的專案裡自動產出BUILD。
從設定檔的放置上去看，相當的正常合理，但看到了設定檔要怎麼寫後，就好像進入到異次元，怎麼樣都不知道要怎麼進行下去。且在網路上找到的幾篇文章，雖然頭頭是道的寫下了每一段設定，但就是沒給git repo，實在是很害怕中間有什麼東西少了，跟著文章做一做就卡住。
還是會希望能夠有文章同時解釋Blaze地很清楚，也有範例可以實際去操作。目前多數找到都是nodejs相關的文章才有範例可以直接用。
接下來就只能花些時間反覆來看Blaze的nodejs專案範例，希望能夠突然理解到底要怎麼使用blaze。
iThome鐵人賽
看影片追技術