# PTT 新版本開發專案-常見Q&A

## 維護人 提莫
###### tags: `Ptt App`、`FAQ`
###### 位置: [主目錄](https://hackmd.io/@twbbs/Root)/常見Q&A

1. 是否可以直接看規格(如果沒有，至少需要重點說明)開發中台 C# ?
* 請參考文件主目錄底下的
* 中介應用層(中台對外API)/專案討論區
* 中介應用層(中台對外API)/Asp版本中台應用層(與Pichu版本底層對接)/開發文件

2. BBS daemon 是自己架的嗎？
* 目前 PTT 的 Daemon 是由PTT站方架設的。
* 目前(2021/07/27)由開發者架設兩個測試站台作為 App 前端測試使用，測試資料與真實站台不同。
* 測試站的部分有一個共用的測試站是由 Codingman 架的。
* 另外如果自己開發需求，需要自行架設也是可以的，或是請洽提莫。

3. 其實對於 BBS 的運作原理還沒有很了解，猜測是一個 server 去 hosting，然後協議是 telnet 這樣？
* 這邊我先不使用 Server 這個詞。我先假設你理解一般的 LAMP 架構，也就是 Linux Apache MySQL PHP 架構。 那在連線進來時， Linux 底層會進行 80或443的TCP 交握，隨後把交握結果交給 Apache, 由Apache 確定要交由哪個行程 Process 處理， Apache 處理完基本的 TLS 以及 HTTP 之後發現是 PHP 程式的請求，即透過同主機內的連線請 PHP-FPM 進行處理，接著PHP-FPM是情況決定是否連線 SQL 後把資訊回傳。
* 而 BBS 的架構簡單一點， Linux 處理完交握的事情之後剩下來的事都是BBS的事情了，因此要走TELNET或是SSH或是任何Protocol 大多數都是在 BBS 的程式上實作的，使用者連線連入後行程會進行 Fork, 一個行程變成兩個，所以如果站上有五萬人，那主機就會有五萬個行程!

4. 中台的意義是？

* 支援新的介面，提供 RESTful API
* 用於專屬官方APP獨有支援的評價與留言功能
* 提供現代化搜尋(實作中文斷詞)
* 增加支援 CDN、Redis
* Log

5. 主要看到有多個中台，.net / go / python 各有一個，且在雙版本架構中，go 版本的中介底層似乎跟 bbs daemon 在同一層級，因此想知道下各個的意義是為何？

* 目前(2021/07/27)實際上就是支持兩個版本的後台與一個版本的中台，分別是：
* 後台中介底層(中台對內資料存取原生BBS層)
* Hsiao版本中介底層(Go) 老蕭負責
* Pichu 版本中介底層(Go) Pichu負責
* 中台
* Hsiao版本中台(中台應用層)(Go) 老蕭負責

6. 對於 websocket 及 grpc 兩者間關係不是那麼清楚，想問下為何兩個會被放在同一塊？

* 架構圖中指的是 term.ptt.cc 的形式，所以區塊中把 websocket 與 grpc 放在同一塊示意。

7. 現在市面上的 app ( mo j ....) 知道他們是用什麼架構嗎？ telnet / ssh / socket ?
* 首先， socket = telnet ，原則上所有的網路連線都可以用 socket 實作。
* 再來 SSH 和 TELNET 的主要差異在連線之前有沒有加密，SSH像是一個大的不透光的牛皮紙袋， telnet 像是明信片，因此即使是透過SSH加密，裡面通常還是直接把明信片裝在這個牛皮紙袋裡面，因此還是會需要用到製作裡面這張明信片的程式碼，只是加上了外面的牛皮紙袋後讓上面的資訊變得安全了許多。
* 而關於市面上的 app ，老實說每個APP的手法可能不同，有些可能會把資料先存在該伺服器，有些可能不會。

8. 有考慮改動水桶系統的計算天數方式嗎？比方說看對方上線時間而非現實的天數之類的?不過這要紀錄離站時間，會有負荷？

* 官方APP專案的範疇，不會改動原BBS的程式碼，所以不會改變原機制。

9. 這專案缺人麼樣的人？

* 這專案需要大家一起來協助，所以歡迎來g0v一起討論。
* 如果你不確定自己是否適合或是能做什麼，可以先從g0v新手導覽開始。

10. 是否會支援水球系統?
* 官方APP專案的範疇，暫無此部分，先把目前目標完成，後續可討論進程。

11. 是否會支援小天使系統?
* 官方APP專案的範疇，暫無此部分，先把目前目標完成，後續可討論進程。

12. 中台應用層與前端連線方式
* 中台應用層對外使用 RESTful API。
* (底層)<-RESTful API->(中台)<-RESTful API->(前端)

13. 為何是中台傳遞 user token 給後端的設計，而不是使用 api key? 一般都是認證串接來源，不會認證串接來源的來源?
* 設計上為了保留中台未來有彈性可以同時支援適應：1.移動至公有雲或2.留在與底層相同內網的環境，讓這兩種環境*都可能*持續維運，認證串接來源的來源是一種候選的解決方案，因此我們選擇實作這機制。

14. 不使用 api key 的考量
* API keys are generally not considered secure; they are typically accessible to clients, making it easy for someone to steal an API key. Once the key is stolen, it has no expiration, so it may be used indefinitely, unless the project owner revokes or regenerates the key. While the restrictions you can set on an API key mitigate this, there are better approaches for authorization.