我有一個關於管理具有多個元件的 Git 專案的基本問題。我所指的項目的架構如下：
project-name
├── cli
├── api
├── webapp
├── docker-compose.yaml
├── README.md
├── LICENCE
我的目標是建立一個優先考慮可維護性和程式碼重用的結構。所以核心功能都內建在Python的命令列介面（cli）中。我也在建立一個rest api，目標是讓它在後台使用cli而不重寫程式碼。
我的第一個問題是：這是一個好方法嗎？我使用了許多基於 API 的 cli（與我的方法相反），例如 AWS。我還使用了基於 CLI 的 API，例如 ffmpeg。所以我不確定就我而言，按照我上面解釋的方式是否有意義。
現在要連結 api 和 cli，我想到了兩種方法，但我不知道哪種方法最合適。
- 方法 A：使用專案內的相對路徑直接從 api 呼叫 cli。但這是否意味著 cli 應始終與 api 一起提供？
- 方法 B：將 cli 單獨建置到 python 套件中並將其發佈到儲存庫上，然後將其用作 API 中的需求。這對我來說看起來“更乾淨”，但這意味著我不會立即看到我在 CLI 中所做的改進，因為我需要再次建立套件並發布它。
我的第二個問題是：哪一種方法是在 api 中引用 cli 的正確方法？ （或者有其他方法嗎？）
先致謝！
答案1
不，這裡有很多問題：
- API 不應使用 CLI。 CLI 應使用 API。
- 雖然您可以將 cli/app/webapp 放在一個儲存庫中，但這被認為是糟糕的設計：它被稱為“莫諾雷波”。通常您需要三個不同的儲存庫，其中 Web 應用程式和 CLI 都會呼叫 API。這也更好，因為一個 Dockerfile 幾乎沒有意義——您是打包一個 cli，還是一個 web 應用程式？我希望 cli 和 webapp 都有一個 Dockerfile。
- 與單一儲存庫相比，使用微型儲存庫的優勢主要在於工具。工具將為這些事情提供更好的支援。
- 使用 microrepo，強制您的 cli 和 webapp 與 API 分開進行版本控制。這總是可取的。例如，您可以開發兩個版本的 Web 應用程式或 cli，同時使用兩個不同版本的 API。從 cli 和 web 應用程式中提取 API，就像任何其他所需的外部依賴項一樣工作。