Moya: Has anyone thought about an AsyncPluginType for Moya?

[SD10]

protocol AsyncPluginType {
    /// Called to modify a request before sending.
    func prepare(_ 
        target: TargetType, 
        callback: @escaping (URLRequest) -> Void
    )

    /// Called to modify a result before completion.
    func process(_ 
        result: Result<Moya.Response, MoyaError>, 
        target: TargetType, 
        callback: @escaping (Result<Moya.Response, MoyaError>) -> Void
    )
}

Just throwing an issue out there, I'm not even sure this is compatible with the Moya internals. I'd need to take a deep dive again.

[pietrocaselani]

@SD10 I think this would be a great addition to Moya!
I already can see RefreshTokenPlugin working with this!

And looking at Moya internals, more specific, the method MoyaProvider.requestNormal, I think would be possible to add this without too much effort.

[SD10]

Thanks for the input @pietrocaselani, I think there could be huge benefits to something like this as well.

In my app I'm faced with a situation where I need to modify a request's parameters asynchronously but not through a request per say. Rather, I just need to access an optional value on some other object that could or could not be nil. So chaining callbacks, promises, or Rx are all useless to me

Right now I'm writing a wrapper around my MoyaProvider to wait for this value to not be nil.
TL;DR this doesn't scale well and creates some tight coupling between my provider and this resource.

I do agree this would work awesome for a RefreshTokenPlugin

[pedrovereza]

The idea seems interesting, but I think it'd be helpful to have a more detailed usage example.

In my app I'm faced with a situation where I need to modify a request's parameters asynchronously but not through a request per say. Rather, I just need to access an optional value on some other object that could or could not be nil. So chaining callbacks, promises, or Rx are all useless to me

@SD10 I'm not sure I understood your scenario, can you clarify a bit more? Specially why callbacks and promises are useless and how the AsyncPluginType would help you 🤔

@pietrocaselani @SD10 since both of you mentioned the RefreshTokenPlugin, any chance you could share how you think the plugin would look like using AsyncPluginType?

[SD10]

Hey @pedrovereza, as I was explaining it I was realizing it was a slippery slope and difficult for people to understand my situation.

To better explain my problem, I need to access an optional resource (a Firebase token) but I'm only given a synchronous API to access it. The resource is set by Firebase internally, asynchronously. Thus I have to block all Moya requests until this resource is available. If that makes more sense?

I've solved this problem without an async plugin, I'm just saying it would help me decouple the relationship between my providers and this resource

That being said -- I think there is value for this in Moya beyond my specific use case as @pietrocaselani has mentioned -- as long as it doesn't introduce a ton of complexity or heavily impact the existing API. I think it would be a good idea to mock up a plugin as an example like you said

[pietrocaselani]

@pedrovereza I am not sure that we could provide a RefreshTokenPlugin implementation direct from Moya. I only mentioned because I implemented a refresh token logic using the RequestClosure API because it's async, and there is no (good) way to do a sync request. So, if we provide a plugin type API that supports async code, would be great for these situations

/// Closure that decides if and what request should be performed.
public typealias RequestResultClosure = (Result<URLRequest, MoyaError>) -> Void

/// Closure that resolves an `Endpoint` into a `RequestResult`.
public typealias RequestClosure = (Endpoint, @escaping RequestResultClosure) -> Void

[SD10]

I agree that I don't want to be supporting async plugins through Moya. I'd just like to make it easier for users to create their own async plugins.

I implemented a refresh token logic using the RequestClosure API because it's async, and there is no (good) way to do a sync request.

This is a really great point ☝️ Honestly, I really dislike that Moya provides 2 ways to do similar things: closures to customize requests and plugins to customize requests. I still hold a long term belief that Moya should deprecate the usage of customization closures on the MoyaProvider and favor a plugin system.

My problem with providing both of these methods is they actually conflict and if you use both combined you can actually end up creating undefined behavior (see #1549).

However, to deprecate something like requestClosure & endpointClosure you would need:

1. an async plugin system to replace the asynchronous capabilities of these closures
2. the ability to stub an endpoint not using a endpointClosure (see #1502)

If you do these two things, you essentially don't need closures any longer. Everything that the closures can do the plugins can

[SD10]

It doesn't hurt to ping @Moya/contributors for any input on the discussion. Things have been slow around here lately 😆

[pietrocaselani]

No updates here?
I was thinking about open a PR implementing this, but I am not sure if I should wait for Moya 12 release before.
What do you think?

[SD10]

@pietrocaselani Yeah this is definitely not a feature that will be in Moya 12.0 — we also need more community input on this subject. Other than that, I would like to finish #1502 before submitting a PR for something like this because they will both make changes related to Moya internals

_{Sent with GitHawk}

[SD10]

@pietrocaselani I tried doing this with the RequestClosure as you mentioned above and it was very difficult because the Endpoint object is useless to me, I need access to the underlying TargetType that's been abstracted away

[pietrocaselani]

@SD10 sorry, what did you try to do using the RequestClosure?
If you are talking about the refresh token login, you can look my implementation of RequestClosure here and here too.

[SD10]

@pietrocaselani this is a really clever approach 💯 that _may_ work for my architecture. I'd argue this is pretty unfriendly though

[pietrocaselani]

@SD10 Thanks! And yes, I agree that is unfriendly and definitely should never be a public API, but it solved my problem.

My "inspiration" was OkHTTP interceptors and authenticator.

[yuliagaranok]

@SD10 @pietrocaselani my teammate found an easy way to refresh session token of Auth0 with RxSwift and Moya basing on all opened and closed issues about token refresh.
Hope it may also help someone to cope with it.

[chyrta]

Hi there, I was the author of the post which Yulia shared here. I got a handy comment from one of the contributors Andrew regarding asynchronicity of the solution. I plan to improve the code to handle such cases, and I will let you know about that.

[AndrewSB]

@chyrta yup, that was me! I'd love to be able to point people to your blog post instead of the issue where I explained something similar. Don't hesitate to reach out if my suggestions weren't clear