Open ogres opened 6 years ago
@ogres thanks for the feedback. I wonder if you can share more with me:
1) Are these dependencies causing issues to the project you're working on?
2) Have you tried customizing the templates and use the -t
option to see if it meets your requirement?
Using only Foundation/Stdlib will allow us to use swagger generated code on Linux as well.
@ogres I believe PromiseKit and RxSwift are truly optional (utilized only with the responseAs config option, for example --additional-properties responseAs=RxSwift
), but yes Alamofire is required at this point for generated code to function. I fantasize about that not being the case, but don't have any cycles to dig into AlamofireImplementations.swift to see how hard it would be to abstract that away.
@ogres thanks for sharing more with.
cc @jgavris @ehyche @Edubits @jaz-ah
Not opposed to this idea...but personally our project is using PromiseKit and we like it a lot! Technically the only dependency right now is Alamofire, +1 additional framework if you want RxSwift or PromiseKit generated.
@ogres : when I wrote our customized "swift3-groupon" for Groupon, I wanted this as well, since we did not want to be locked into using Alamofire. Instead, we wanted to be able to swap out any HTTP stack implementation: Alamofire, a simple URLSession implementation, etc.
In our swift3-groupon generator module, I created a protocol for a simple HTTP client and then injected that protocol in the constructor of the API client. Then the generated API client calls that injected HTTP client when needed to fetch the raw HTTP response. Then, in the same generated module, I also provided a simple implementation of that HTTP client using URLSession, so that the samples could work "out of the box".
We could take a similar approach with the swagger-codegen swift4 generator module as well, if folks like this approach. But it's a lot of work to get there. @ogres : what do you think?
@jgavris @Edubits @jaz-ah : what do you guys think?
Thanks @ehyche ! Sounds awesome, that would be even better for testability
Hi all,
Just want to share that we can provide multiple HTTP library support for Java client generator by making "ApiClient.java" swappable. Currently, we support Jersey 1.x, 2.x, Retrofit 1.x, 2.x, Feign and more in the Java API client.
Not sure if we can do something similar in the Swift 4 client but worth sharing with you guys so you may consider using similar approach.
I completely agree. I try to keep the number of third party libraries at a minimum. They increase compile, deploy and launch times and add bugs. Not to mention the more libraries you add, the quicker you end up in 'dependency hell', where you can't upgrade or add libraries any more. And I don't get the point of Alamofire TBH. Everything it does can be done with NSURLSession and a few lines of code. And forcing RxSwift and PromiseKit is completely unneccessary.
I agree with removing dependencies in defaults. Now that RxSwift and PromiseKit is optional as @lightbow said. So we should make Alamofire optional also. Then we can add additional option for another HTTP Client.
I have another reason for why should be optional to have another framework. for example in my project, we are using Alamofire 5.0.4 however for the generated swift client is using Alamofire 4.9. in this case, there is compile error.
Description
Generated code for Swift 4 requires frameworks,
https://github.com/swagger-api/swagger-codegen/blob/master/modules/swagger-codegen/src/main/resources/swift4/Cartfile.mustache
Would be better to be able to use Swagger generated client without any third party frameworks. Codegen should only rely on Foundation and Standard Library.
Generated code should work with URLSession
Suggest a fix/enhancement
Would be better not to have any third party dependency. Codegen should only rely on Foundation and Standard Library. Generated code should work with URLSession instead.
If many people like and use current format, we could have two separate codegen formats, with and without dependencies.