[Haskell] Refactor generator to create separate client, server generator

[wing328]

Description

Currently, Haskell generator (HaskellServantCodegen.java) generates both client and server code. We want to refactor HaskellServantCodegen.java into the following:

HaskellServantCodegen.java - for server
HaskellClientCodegen.java - for client
AbstractHaskellCodegen.java - abstract class for client/server generator

The goal is to make Haskell generator more consistent with other generators (as no other generator output both client and server code at the same time)

Swagger-codegen version

Latest master

Suggest a Fix

If anyone wants to contribute the enhancement, please reply to let us know.

[mandrean]

👍

Cross-referencing my comment from #5097:

@wing328 Thanks! Yes, I think it's a very good idea to split them up.

Also, it might be a good idea to evaluate other solutions for the client. I don't think servant-client is the best choice here.

I would go with http-client, which is used by many other high-profile Haskell packages (as you can see in the Used by 256 packages: section on Stackage), including PureScript, Yesod, stack it self, and many others.

[wing328]

@mandrean sounds good to me to use http-client. If a user still prefers servant-client, we can simply keep it in the current generator (for backward compatibility)

[mandrean]

Another option could be https://github.com/bos/wreq which is based on http-client but supposedly easier ridiculously easy to use! (http://www.serpentine.com/wreq/#whirlwind-tour)

And it has built-in support for Basic Auth and Oauth2.

My vote goes to wreq for now.

[wing328]

Both http-client and wreq look good to me. For Java API client, it now supports the following HTTP libraries via the library option/switch:

	library
	    library template (sub-template) to use (Default: okhttp-gson)
	        jersey1 - HTTP client: Jersey client 1.19.1. JSON processing: Jackson 2.7.0. Enable Java6 support using '-DsupportJava6=true'. Enable gzip request encoding using '-DuseGzipFeature=true'.
	        feign - HTTP client: Netflix Feign 8.16.0. JSON processing: Jackson 2.7.0
	        jersey2 - HTTP client: Jersey client 2.22.2. JSON processing: Jackson 2.7.0
	        okhttp-gson - HTTP client: OkHttp 2.7.5. JSON processing: Gson 2.6.2. Enable Parcelable modles on Android using '-DparcelableModel=true'. Enable gzip request encoding using '-DuseGzipFeature=true'.
	        retrofit - HTTP client: OkHttp 2.7.5. JSON processing: Gson 2.3.1 (Retrofit 1.9.0). IMPORTANT NOTE: retrofit1.x is no longer actively maintained so please upgrade to 'retrofit2' instead.
	        retrofit2 - HTTP client: OkHttp 3.2.0. JSON processing: Gson 2.6.1 (Retrofit 2.0.2). Enable the RxJava adapter using '-DuseRxJava[2]=true'. (RxJava 1.x or 2.x)

Supporting multiple HTTP libraries is possible via a "swappable" ApiClient class.

My suggestion is to go with the HTTP library that you feel comfortable. Later there may be enhancement to support HTTP libraries when more and more Haskell developers discover Swagger Codegen.

[mandrean]

Great suggestion. Super busy at work right now, bu I'll try to squeeze out a feature-complete wreq PoC for Petstore.json, then we can start templating the codegen from there.

[jonschoning]

my vote would be for http-client over wreq, as http-client avoids a dependency on lens (& assumes familarity w/ lens operators) (and has less deps in general), is more actively maintained, and is more straightforward imho.

Actually, it would not be unreasonable to have multiple haskell client generators as some of the other languages do. that way the servant generator could be kept.

[nvmd]

I'm working on a gradual improvements to haskell-servant right now. Generated code itself first, and codegen refactoring after that.

[wing328]

@nvmd thanks. If the enhancement is not backward compatible with the existing code, then please file it against 2.3.0 branch. Any questions just let us know.

[wing328]

Hi all, when you've time, please try the Haskell http-client generator by @jonschoning : #6429