无论在使用场景还是开发场景，或多或少会遇到一些无法理解为何如此设计的问题，这里我们会尽量解答这些问题。
我曾使用 PHP / Laravel 的技术栈开发 CHEMEX 和 CAT，得益于 DcatAdmin 或者 FilamentPHP 框架，整个开发过程非常快速，很容易就形成了一个全栈应用。 但是，随着应用的增长，以及多平台的需求，我发现前后端分离的优势越来越明显。如今的 PHP 生态已经不言而喻，即使它仍然是流行的后端语言。 很多情况下，针对一个业务流程的开发，我会投入额外的时间去处理一个前端页面上按钮事件，这又引出不同全栈框架针对前端渲染的不同处理方式，我不想在这方面浪费时间。 如此一来，也为了摆脱前端在上游的依赖，我决定使用前后端分离的方式去开发。
说来有趣，我对命令行程序有一种执念，主观上认为这样的操作方式对 IT 从业者来说非常的酷。好吧，其实是我不想过多的花费时间在前端页面的处理上，这些 我打算交给社区来处理，我提供接口文档，社区可以根据自己的需求来开发自己的前端页面。这样一来，我可以专注于后端的开发，而不用去关心前端的开发。 但是为了让大家更好的使用，我还是提供了一个命令行客户端，这样可以让大家更好的体验。
从始至终，这个系统不是一个专注于高并发的应用程序。很多人都在讨论 Python 的性能，但是我认为 Python 的性能已经足够满足这个系统的需求。 Python 有着丰富的生态，很多的库可以让我快速的开发出一个功能。我不想在这个系统上花费太多的时间，所以我选择了 Python。
FastAPI 是一个非常优秀的 Python Web 框架，它的性能非常好，而且它的文档非常全面。我认为这是一个非常好的选择。我的目标在于快速完成业务逻辑处理的同时就能 马上输出接口，而 FastAPI 正好满足了我的需求。实际上，你可能会发现目录结构与 FastAPI 官方文档中的例子有很多不同，这是我做了一些调整。
为什么使用了 SQLAlchemy ORM 却没有使用它的关联关系处理业务逻辑？ Why use SQLAlchemy ORM but not use its association relationship to handle business logic?
这是一个让我很头疼的问题，我曾经尝试过使用 ORM 的关联关系来处理业务逻辑，但是我发现这样的处理方式并不适合我，原因如下：
1，SQLAlchemy 的 ORM 本身并不是完全在业务逻辑层实现，其本身还需要依赖数据库表结构，例如外键，这在一定程度上会约束后端数据库引擎的配置。 2，它的关联关系仅在处理简单的业务逻辑时才能发挥作用，一旦业务逻辑变得复杂，我发现我需要写很多的代码来处理这些关联关系，这样反而增加了我的工作量。 3，用户可能会选择不同类型的数据库引擎，我希望把这部分的依赖弱化，而是在业务逻辑的代码中去处理这些关联关系。
不要过度封装和抽象，面向对象开发是很好的理念，但是很多时候的业务逻辑思路需要灵活的处理、良好的代码可读性，而不是让用户在开发维护过程中从不同的 函数间跳转搜索业务逻辑。在接口控制器中，这是面向流程的，用户可以很容易的看到整个业务逻辑的处理流程。这样的代码看起来冗余，但是却是非常直观的。
为什么服务器端没有做多语言支持，而客户端确支持多语言？ Why is there no multi-language support on the server side, but multi-language support on the client side?
用户是和客户端程序打交道的，而不是服务器。在前后端交互中，使用标准的 HTTP 响应状态码来反馈请求结果，客户端根据状态返回不同的提示信息。 这完全可以在客户端实现，没有必要在服务器端实现，多语言也是一项拼工作量的功能。