We can choose to generate and use a model without external dependencies.
We can use our own Service infrastructure to make the request, without the need of the generated client.
All model seem to be generated properly, and with camelCased fields.
The Apple's generator seems to have issues with a couple of types like here.
Drawbacks over Apple's generator:
This generator is a Java cli.
To avoid all Java dependencies, I opted for a Docker based option.
Docker needs to be installed and running to generate the code.
The generated structures used by profile (like ProfileContactInfo) are not nested to the Profile struct. This is not terrible but it would be a nice-to-have.
Generating the code with make install-and-generate (when openapi-generator have not been yet cloned) is really slow.
On this example, I opted for having Profile public, I'm not very happy with this, but the extra boilerplate of wrapping it in a different struct seems unnecessary now, keeping in mind that we can have control (or at least a vote) on yaml spec changes (up to debate).
This is an alternative to https://github.com/Automattic/Gravatar-SDK-iOS/pull/248
On this PR we use https://openapi-generator.tech/docs/generators/swift5/ instead of https://github.com/apple/swift-openapi-generator .
Benefits over Apple's generator:
Drawbacks over Apple's generator:
ProfileContactInfo
) are not nested to theProfile
struct. This is not terrible but it would be a nice-to-have.make install-and-generate
(whenopenapi-generator
have not been yet cloned) is really slow.On this example, I opted for having
Profile
public, I'm not very happy with this, but the extra boilerplate of wrapping it in a different struct seems unnecessary now, keeping in mind that we can have control (or at least a vote) on yaml spec changes (up to debate).Testing Steps