swagger-api / swagger-codegen

swagger-codegen contains a template-driven engine to generate documentation, API clients and server stubs in different languages by parsing your OpenAPI / Swagger definition.
http://swagger.io
Apache License 2.0
17.01k stars 6.03k forks source link

[Swift] Generate Swift client w/o dependencies #6914

Open ogres opened 6 years ago

ogres commented 6 years ago
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.

wing328 commented 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?

ogres commented 6 years ago
  1. I am trying to reduce number of dependencies to lower number dynamic frameworks loaded on app launch, reduce app size, reduce possible bugs ( introduced in 3rd party libraries ).

Using only Foundation/Stdlib will allow us to use swagger generated code on Linux as well.

  1. No, unfortunately I have not tried it, first I wanted to get a feedback and see if this is something already considered.
lightbow commented 6 years ago

@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.

wing328 commented 6 years ago

@ogres thanks for sharing more with.

cc @jgavris @ehyche @Edubits @jaz-ah

jgavris commented 6 years ago

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.

ehyche commented 6 years ago

@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?

ogres commented 6 years ago

Thanks @ehyche ! Sounds awesome, that would be even better for testability

wing328 commented 6 years ago

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.

knlr commented 6 years ago

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.

d-date commented 6 years ago

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.

chauchinyiu commented 3 years ago

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.