Generating clients for multiple languages

[boldtrn]

I am currently trying to create Swagger clients using the Swagger-Codegen for multiple languages. Everything is fine for a single language, but when doing it for multiple languages the complexity seems to increase unnecessarily.

Some of the options in my config.json file are not supported/available in other languages and therefore I would have to create a config file for every language, which makes it for example ridiculous complex to do a version bumb. So my current approach would be to write a script that calls the Swagger-Codegen several times passing different config parameters per language. However, this seems more like a hack than a solution, so I was wondering if I missed anything in the docs or if any of you came up with a better solution?

In the end I would like to generate clients for most of the available languages of the codegen.

A possible solution for the codegen could be to extend the current config file format. Maybe it would be possible to create a structure like this:

{
version: 1.0
groupId: "group"
artifactId: "artifact"
languages: {
  java: {
    library: "okhttp-gson"
  },
  php: {
    phpOnlyValue: "something"
  },
  someOtherLang: {
    foo: "bar"
  }
}
}

The idea would be to have a lot of common attributes that only need to be changed once, for example the version, the name of of the client, and the name of the organization (groupId).

If you compare the config options for php and java they are completely different. It would be nice to have a common subset of configs for each language (not sure if this is even possible in theory).

What do you think? Is there a different/better way to do this right now?

[wing328]

@boldtrn thanks for the suggestion. Putting everything in a config is definitely one way to do it.

Personally I prefer separate configurations into different files for easier management. I've seen issues before that someone made a mistake in a giant config shared among different teams and as a result multiple systems were impacted. (this is not to say a huge config file is always a bad idea but starting out with several small config files for each API clients may be easier to manage if the config grows bigger and bigger over time)

I would also like to point out that the version for the SDK (e.g. 1.0.23) may not be in sync among all SDKs (e.g. PHP, Ruby, Python) as more and more enhancements, bug fixes are added to Swagger Codegen. Imagine the situation there's an improvement (additional non-breaking feature) in the PHP API client. What I would suggest is to release a new version just for PHP SDK (e.g. 1.0.24) while other SDKs stay the same version (e.g. 1.0.23) as there's no change to those auto-genreated SDKs. Of course one can wait for a stable release of swagger codegen and release the SDKs with a newer version (e.g. 1.0.24) to keep the SDK version in sync among different API clients.

[boldtrn]

@wing328 thank you for your answer.

You are right, it might not always be a good idea to write a big config file. IMHO right now it is too complicated to create clients that follow the best practice of the underlying language.

So how about creating a meta config that defines what languages to create (maybe referencing the language configuration file?) and a common set of attributes, for example the name of the client and the name of the organization/group.

So the default behavior would be to generate clients that follow the best practice of the languge (convention over configuration). The name of client would be put in every client using for example either camel case, snake case, you name it. In the config file per language these defaults could be overwritten if one needs something special, like a minor version bumb for a certain language, or different naming, etc.

For me as a developer it is tedious to look at the language help for every language, research the preferred defaults for the language, setup a repetitive config with slight changes, like camel case vs. snake case.

So what I did is to create a script that does these things, but I don't have the time to lookup all the language conventions so it is only configured for the languages I understand.