问题描述
我正在对 NxWorkspace 及其在现有 .Net Core 解决方案中的实现进行测试，在该解决方案中，我们有多个可以从 NxWorkspace 中受益的 Angular 应用程序。我了解在创建没有 .Net Core API 的新存储库时这将如何工作，但我很难想象将 NxWorkspace 实现到我们现有的存储库。
在将 Nx 与 .Net Core（或非 JS 技术）结合使用时，我试图找出的最佳实践是什么？ Nx 是否必须位于根目录中，或者如果它位于下一层的文件夹中是否重要？我已经完成了 NxWorkspace 视频讲座，所以我了解了 Nx 的实用性，但在如何将其应用于我们现有的存储库，或者它是否应该具有它的好处方面做得不够。例如：
之前
根目录中的当前文件夹结构，省略了 OpenShift、Docker 和管道工件：
/dotnet-webapi
/client1-angular
/client2-angular
/client3-react
之后
在 /client-workspace 中使用 NxWorkspace 的新文件夹结构：
/dotnet-webapi
/client-workspace (NxWorkspace)
/apps
/client1-angular
/client2-angular
/client3-angular
/libs
/tools
对比
根中的 NxWorkspace 即使它根本不会使 .Net Core API 受益，而且感觉就像将 API 埋在 JS 生态系统中一样：
/apps
/dotnet-webapi
/client1-angular
/client2-angular
/client3-angular
/libs
/tools
解决方法
我们在工作中为我们的 Angular 应用程序利用了几个内部 .NET 核心 API，但目前我们的 monorepo 仅包含 Angular 应用程序。我们肯定已经感受到这些好处，并希望最终扩展它以容纳 .NET API。
后两个版本中的任何一个都应该可以正常工作。就个人而言，我们正在推迟将 .NET 项目添加到 monorepo 中，直到一个类似于 Nx Community GO 插件的好插件出现在 .NET 中。创建该插件后，我们将采用您的第二个版本的策略，其中apis 在apps 目录下。
虽然您认为目前它不会从中受益是正确的，但一旦创建了一个好的 .NET 插件，您就可以将其添加到 workspace/nx.json 并开始获得一些好处。这些好处将包括计算缓存、build:affected 等，尽管无法从应用堆栈的打字稿部分引用它们。