开发人员全面考虑创建一个全栈Web应用程序，从使用Angular创建前端到使用后端的微服务。
最近我有幸成为一个项目的一部分，我们正在从头开始构建一个应用程序到后端的微服务Angular前端应用程序。Swagger被用作UI和微服务之间的契约。
在这篇文章中，我将讨论从项目经验中学到的东西，比如如何使用Swagger定义微服务的端点，将Swagger生成的代码集成到Angular中，以及使用包括oAuth2令牌在内的配置，以及其他“陷阱”。
更多地了解Angular
如果您阅读我之前关于PWA的博客，那段时间我就是在教自己Angular4+。我知道这个项目会给我我需要的经验。由于我阅读的Angular教程和文档非常容易上手，因此没有那么多“陷阱”进入项目;我的意思是认真，通过AngularTourofHeroes教程，你会学到很多东西。花费一些时间让我掌握的部分是ReactObservables的概念。
输入Swagger
Swagger是一种用于设计和构建API的工具。这个工具非常方便。
该项目将使用Swagger来定义微服务的端点。
首先，我们以Swagger文档（YAML或JSON格式）设计端点。然后我们使用它不仅为API服务器生成代码，还为API客户端生成代码。因此，我们可以很好地定义我们需要的端点，然后从中生成代码，这对于聚合开发会话（例如敏捷的mob编程）很有价值。
将Swagger生成的代码集成到Angular中
对于我的情况，我能够从我们定义的Swagger文档生成AngularTypeScript代码。代码Swagger生成的一些东西让我摸不着头脑。它生成了域模型和API服务，但是，它生成的其他东西我认为我们不需要......但最终会在以后使用。
我开始将API服务代码（这是用于与API交谈的代码）引用到我们的应用程序模块中，忽略了Swagger生成的API模块。如果Swagger文档发生了变化，我将API模块导入到我们的应用程序模块中。这样可以更轻松地复制生成的API模块，而不是更改应用程序模块。
说到Swagger文档何时发生变化，我提出的一种方法是确保我们不修改Swagger生成的代码。如果我们开始编写业务逻辑或在Swagger生成的代码中改变一切，那将是一场彻头彻尾的噩梦。这将导致Swagger文档发生更改，这意味着我们必须重新生成代码并将其与现有代码合并。相反，我们决定在此处应用包装器模式，并将Swagger生成的服务代码注入到具有业务逻辑的另一个服务类中。这样，如果我们需要重新生成Swagger代码，我们可以简单地复制它而不用担心业务逻辑的变化。
配置难题
既然我们已经有了与API交谈的代码，那么现在是时候与API进行交流了。首先，我们需要让代码指向APIURL。第一直觉就是将URL硬编码到API服务中（同样，Swagger生成的代码与API通信）。请记住，如果可能，我们会尝试不更改生成的代码。
我发现的其中一件事，直到项目的后期才考虑，是configuration.tsSwagger生成的文件。这是一个例子。配置类被注入API服务代码并用于建立与API的连接。例如，basePath配置类中的属性包含API服务用于进行API调用的API的URL。
我们必须找到一种方法来创建一个配置实例，其中填充了要使用的API服务代码的正确值。添加到混合中的是我们需要传递给API的OAuth2令牌。我们已经有了一个与IDP服务器通信的服务，并为我们提供了OAuth2令牌。
但是，我们需要找出在Configuration类中使用该标记的方法。每当API调用API时，API服务代码已经完成了在标题中包含令牌的工作（顺便说一下超级方便！），我们只需要通过Configuration类提供令牌。
经过长时间的搜索，我找到了一种方法，使用了Angular的ProvideFactory。在定义要提供的内容时，在应用程序模块中，您可以指定它的创建方式。请参阅以下代码示例：
functiongetConfig(myAuthService:MyAuthService){returnnewConfiguration({basePath: