In our app we use Firebase, we would love to abstract this to the point where we can use alamofire or firebase without the caller knowing anything.
As it is we will have to either have an abstraction of an abstraction or have the code know it's calling Moya or non-moya code.
Hmm, this is an interesting question. There's no reason we can't/shouldn't do this, it's just never been a priority before, so it's definitely worth considering. I'm thinking we abstract the functions we call from Alamofire into protocols, and extend Alamofire types to conform to those protocols. Then we just need a way to specify a different set of types that also conform.
There's a bit of hassle where we're currently using typealias to create Moya-specific types from Alamofire ones (for things like request methods, GET, POST, etc) that would need a little bit more code, but nothing too dramatic.
I've got a flight tomorrow, might take a stab at this on the plane. In the meantime, you could explore subclassing Moya's Provider class to give you similar behaviour. Please let us know if you have ideas for implementation, too.
My fork has done this (which we'd talked before)
I forgot about that, thanks!
I took an initial stab at this, it's quite an overwhelming change. We actually lean on Alamofire a lot, include use of typealias to create Moya types that are really just Alamofire types. If we do this, I would want someone to be able to theoretically use Moya without having any reference to Alamofire code at all.
@jasl how up-to-date is your fork? Moya has added multipart form uploading and a few other large structural changes recently, would it work with those changes?
@ashfurrow I sync all commits to https://github.com/jasl/Moya and it's a fork of Moya.
I'm afraid my fork has large different with current Moya, because I've done myself version of multipart-upload, new Swift 3 naming convention, refactor example, non-generic provider etc before (more early than Moya has these feature).
Okay, thanks for the quick response!
I tried to tackle this from top-down, like replacing our references to Alamofire.Manager with a new protocol defined in Moya, but _everything_ broke immediately, and I was no where near finished an hour later. I think a better approach would be to remove the typealiass in Moya+Alamofire.swift first, then replace use of Manager with a new protocol. I'll see what I can do later.
In my fork, I wrap network engine into Backend which handle initiallizing and configuring the engine, and it's has a request method, that accept Moya's Endpoint value.
In request method, the backend should handle how to make a Endpoint become to request and launch it, then invoking response closure when get response, Moya don't care about how to encode the parameter or how to make endpoint to request, these job is NSURLSession's or Alamofire's, Moya just provides a easy way to encapsulation the remote API definition, and give a easy way to intercept the upcoming Endpoint. I think this is the core value of a networking abstraction.
and I think using typealias isn't a good way to abstract engines, because engines interface are different, and may need to configure, so we need to wrap them.
I don't think there's enough common ground to abstract AlamoFire (one request -> one response pattern) and Firebase (one subscription -> 0..N events in a stream), at least not on Moya's level.
Moving the abstraction up a layer works nice though: RxSwift is great for mapping both variants into streams. (I use it all the time.)
@vzsg yeah currently thats what we are doing.
I tried abstracting Alamofire and found Moya to be too tightly coupled to it to reasonably separate. This is probably because we've always built Moya on top of Alamofire, the de facto standard networking library on iOS. This is a reasonable hard dependency from my perspective, but as always, it's open for discussion. If anyone would like to send a pull request with this specific feature, I'd be happy to look it over :+1: In the mean time, we can keep this issue open in case others have ideas or suggestions.
Since there hasn't been any activity on this thread for some time, I am going to go ahead and close it. Please re-open or create a new issue if you would like to discuss further. Thanks.
I understand this is an old and closed thread but I recently started working on a project for Firebase inspired by Moya. I've called it Nora. I'm really a huge fan of the Moya networking abstraction pattern. I initially tried seeing if Moya could support Firebase but like others in this thread have mentioned, Moya is too tightly coupled with Alamofire and it would require a different Provider and Target types. Thank you everyone for your hard work on this project and the inspiration.
Thanks for the kind words, @SD10, and good luck with Nora. :)
Most helpful comment
I understand this is an old and closed thread but I recently started working on a project for Firebase inspired by Moya. I've called it Nora. I'm really a huge fan of the Moya networking abstraction pattern. I initially tried seeing if Moya could support Firebase but like others in this thread have mentioned, Moya is too tightly coupled with Alamofire and it would require a different Provider and Target types. Thank you everyone for your hard work on this project and the inspiration.