托特 thoth － 技術棧各框架選擇
一人設計、前端、後端、部署怎麼選？我選擇先做出來再說…還有骯髒 Coding 流…。這邊的內容非常多技術名詞，所以隨便看就好：）
一樣正文前要先釐清一下責任，以下寫的只是個人當下的思想，僅供參考 :)
我想分享一下我用的開發工具、框架還有我的開發思路，這方面每個人應該都有不同的見解。
😲 還記得從前某一天開始想要做這個 Idea 的時候是很興奮的。想要做一個很 Fancy、用各種先進或是主流技術框架，現在想想其實還挺自找麻煩的…，太多東西要熟悉導致進度非常緩慢，後來就停擺了。
前端 Before
前端部分，當初用了 Create-React-App + Typescript + React Apollo（GraphQL），我感覺問題不大，因為整體與工作上用到的還是挺相近的，除了當時要自己設定 Typescript tsc 的一些 config 花了些時間（當時Create-React-App 還沒內建支援 Typescript）。
除此之外，我想說交換技能應該要讓用戶能夠互相聯繫，需要做一個Chat的功能。它需要一個 WebSocket 連接前後端，那在 GraphQL 上需要做 Subscription，這部分因為沒碰過也是花了點時間，而且最後在處理 Apollo Cache 上好像還留有不少問題…。
前端 After
要知道要做的事真的很多，考慮到第一版本肯定沒人用，所以我就不想用太酷的東西了…。第一件事先捨棄了 Typescript ，回頭用起了 Javascript。
很多人可能不同意，但我個人不是個 Typescript 的高手，有時候 Type 要放什麼都不知道，會浪費很多時間。尤其是要給 GraphQL query 加上 Typescript 是件相對麻煩的事。 反正一開始 Code 也不複雜，直接Javascript實現就行了！
再來直接捨棄了聊天功能。第一版本，沒必要啊！🤣🤣。這種勞民傷財的事情還是等有流量了以後再來考慮，先找個簡單的替代方式比較實在！
後端 Before
這部分我磕磕絆絆研究了很久。工作上熟悉的一套是：Django + MySQL + Graphene + MySQL，但我個人偏見覺得 Django 不是個能輕易搭配 GraphQL 的好東西。我當初的想法是前後一家親，Node.JS 感覺才是最配 Apollo 的語言(前端選用 React Apollo)，所以想要找出支持 Typescript 的後端框架。
印象中一開始試了 Prisma，後來覺得很不習慣他的 DB 概念就放棄了。挺熟悉 Django 的ORM，覺得它的ORM實在太神，所以想找個 Node.JS 的 ORM 框架。我勉強找出了 TypeORM，聽說 Node 的 ORM 框架目前還沒有能跟 Djanog ORM 媲美的。
DB 部分存粹就是聽說 Postgres 很主流，想用一波 😃。
結果不能說失敗，就是得花不少時間去寫，因為新東西沒一個熟的。而且我當時感覺 TypeORM 似乎還沒這麼成熟，網上討論也相對少，遇到問題挺難解決，不太是個 Production Ready 的工具。
WebSocket 部分你需要使用 PubSub 綁定 Apollo 去通知前端，記得我當時卡了挺長時間在這。
後端 After
後端後來也砍掉重練了，一樣要走精簡風！NodeJS + ExpressJS + Apollo Server 這個簡單的部分保留了，我把 TypeORM 、 Postgres 跟 WebSocket 給捨棄掉，然後加上了 Firestore 這個與之前差距很大的 NoSQL 類雲端資料庫。
Why Firestore? 我覺得 NoSQL 在開發初期好像會比較輕鬆寫意，再加上少了安裝跟設定DB的時間，效率高上不少。但實際上也是花了些時間研究了 Firestore 的概念，畢竟從關連式資料庫轉換成NoSQL一開始也是很不適應的。
Firestore 官方似乎是提倡直接前端使用，配合 Cloud Function 可以省去寫 Server 的時間。我因為還是想用 GraphQL，所以最後用了Server，讓 NodeJS 去跟 Firestore 溝通。
心得
文章有點亂了就先停在前後端實現這裏，還有其他的技術點就之後再分享。 以上的策略依舊是走快速開發模式，一個平台再怎麼 Fancy 沒人用也是白做工。在只有一個人的 Resource 的情況下，能 Dirty 但快速的寫法就先用了。有些地方發現有效能上的問題或是資源上面的浪費也先不出裡處理、有些API 有 Race Condition 也只是先註解，然後功能上不好實現的就先尋求 Workaround OK 吧？
最後還是希望各位可以用用看這個平台，發一篇文章然後給一個你精闢的反饋🙏。