rxswift 网络请求_使用RxSwift将身份验证请求链接到多个服务

rxswift 网络请求

At a company that I have worked in the past, a high-traffic online classifieds, the backend was transitioning from a monolithic architecture, to a micro-services one.

在我过去工作过的一家公司中，这是一家人流量大的在线分类广告，其后端正在从单一架构过渡到微服务架构。

At the time I joined, the apps had to consume some endpoints from the legacy (monolith) backend, and some endpoints already migrated to the new backend. For example, getting the User’s details were on the old one, but getting the favorited items were on the new one.

在我加入时，这些应用程序必须使用旧版(整体式)后端中的一些终结点，并且某些终结点已经迁移到了新的后端。 例如，获取用户的详细信息是在旧项上，而获取喜欢的项是在新项上。

The backend engineers haven’t considered the creation of a single interface in order to handle the login in both architectures, meaning the apps needed to authenticate the user into both backends independently.

后端工程师并未考虑创建单个界面来处理两种体系结构中的登录，这意味着需要独立验证用户到两个后端的应用程序 。

Furthermore, the access token returned from the legacy backend, had to be sent as a parameter when authenticating on the new backend.

此外，从旧版后端返回的访问令牌必须在新后端上进行身份验证时作为参数发送。

The existing implementation, using NSOperation, was buggy and hard to debug/maintain.We decided to rebuild the flow from scratch using RxSwift, because provided an easy way to chain async network requests, map responses into another observable, handle error scenarios, and unit test using RxTest & RxBlocking. We were already using RxSwift in other parts of the app.

现有的使用NSOperation的实现存在错误，并且难以调试/维护。我们决定使用RxSwift从头开始重建流，因为它提供了一种简便的方法来链接异步网络请求，将响应映射到另一个可观察到的，处理错误情况和单元使用RxTest和RxBlocking进行测试。 我们已经在应用程序的其他部分中使用了RxSwift。

If you are unfamiliar with Reactive Programming, I recommend this article: https://medium.com/@saru2020/introduction-to-functional-reactive-programming-using-swift-ea30b1e38309

如果您不熟悉响应式编程，建议您阅读以下文章： https : //medium.com/@saru2020/introduction-to-functional-reactive-programming-using-swift-ea30b1e38309

原子性 (Atomicity)

One important consideration we had to take into account, is the fact that both requests need to succeed in order to update the app state. If either of the auth requests fails, the whole login operation is considered as failed.

我们必须考虑的一个重要考虑因素是两个请求都必须成功才能更新应用程序状态这一事实。 如果任何一个身份验证请求失败，则整个登录操作将被视为失败。

The flowchart is pretty straightforward:

流程图非常简单：

Authentication in both backends needs to succeed

两个后端的身份验证都需要成功

实作 (Implementation)

Let’s start by creating a protocol to authenticate using Username and Password.

让我们从创建一个使用用户名和密码进行身份验证的协议开始。

This is the only method that will be exposed from the network layer. It will return a Single of type Void. A Single is basically an observable that can emit either one value or error.

这是从网络层公开的唯一方法。 它将返回Void类型的Single 。 从本质上讲， Single是可观察的，可以发出一个值或错误。

Then we create private methods to authenticate on each backend, and a private method to store locally the tokens:

然后，我们创建用于在每个后端进行身份验证的专用方法，以及用于在本地存储令牌的专用方法：

Finally, with the private methods in place, we can write the body of the public method authenticate(username: String, password: String)

最后，在使用私有方法的情况下，我们可以编写公共方法的正文authenticate(username: String, password: String)

The implementation looks clean and easy to understand thanks to chaining methods and the use of flatMap. When the login is successful we will emit a Void value. Any error returned by any of the private methods will be surfaced and stop the execution of the following chained methods. Therefore, the subscriber can be configured as follow:

由于采用了链接方法和flatMap，因此实现看起来干净整洁，易于理解。 登录成功后，我们将发出一个Void值。 任何私有方法返回的任何错误都将浮出水面，并停止执行以下链接方法。 因此，可以将订户配置如下：

映射错误 (Mapping errors)

I mentioned before that any error returned by the private methods (eg: network error, server error, validation error) will be surfaced and ultimately returned to the client consuming the protocol AuthProtocol.

我之前提到过，私有方法返回的任何错误(例如：网络错误，服务器错误，验证错误)都会浮出水面，并最终通过消耗协议AuthProtocol返回给客户端。

However it is possible that for simplicity and/or to hide internal behaviour, we want to just map the internal error to another.

但是，为简单起见和/或隐藏内部行为，我们可能只想将内部错误映射到另一个错误。

We can achieve that using the operator catchError

我们可以使用运算符catchError来实现

结论 (Conclusion)

Reactive programming is a broadly used paradigm, as an alternative to Imperative programming, because provides an easier way to handle async calls, manipulate the results through the large number of operators, and a cleaner code organization.

React式编程是命令式编程的替代方法，是一种广泛使用的范例，因为它提供了一种更轻松的方法来处理异步调用，通过大量运算符操纵结果以及更简洁的代码组织。

A disadvantage of using 3rd party libraries like RxSwift or ReactiveSwift, is that your code will be depending on the evolution of the library, that is embedded in several layers of your app, and it’s going to be a non-trivial task if you decide to use another paradigm, or replace the existing library for another.

使用RxSwift或ReactiveSwift之类的第三方库的缺点是，您的代码将取决于库的演进，该库嵌入在应用程序的多个层中，如果您决定使用另一个范式，或将现有库替换为另一个。

The new framework Combine introduced in the WWDC19 by Apple, proposes a native solution to reactive programming, and an alternative to the 3rd party libraries mentioned above.

苹果公司在WWDC19中引入的新框架Combine提出了一种React式编程的本机解决方案，以及上述第三方库的替代方案。

翻译自: https://medium.com/flawless-app-stories/chaining-authentication-requests-to-multiple-services-using-rxswift-91bf3b822c58

rxswift 网络请求