Go-swagger: Explain differences between this project and swagger-codegen Go generator

Created on 7 Mar 2016 · 5Comments · Source: go-swagger/go-swagger

Swagger-codegen can now generate Go libraries too. Which one should I use? Could somebody please document it with something like a feature matrix comparing the two, so it is easier for people to get the best tool for the job they need done?

question

Source

jiridanek

Most helpful comment

tl;dr The main difference at this moment is that this one will actually work.

The swagger-codegen project only generates a client and even there it will only support flat models.

This project supports most features offered by jsonschema including polymorphism.
It allows for generating a swagger specification from go code.
It allows for generating a server from a swagger definition and to generate an equivalent spec back from that codebase.
It allows for generating a client from a swagger definition.
It has support for several common swagger vendor extensions.

Why is this not done in the swagger-codegen project? Because:

I don't really know java very well and so I'd be learning both java and the object model of the codegen which was in heavy flux as opposed to doing go and I really wanted to go experience of designing a large codebase with it.
Go's super limited type system makes it so that it doesn't fit well in the model of swagger-codegen
Go's idea of polymorphism doesn't reconcile very well with a solution designed for languages that actually have inheritance and so forth.
For supporting types like [][][]map[string][][]int64 I don't think it's possible with mustache
I gravely underestimated the amount of work that would be involved in making something useful out of it.
My personal mission: I want the jvm to go away, it was great way back when now it's just silly (vm in container on vm in vm in container)

casualjim on 7 Mar 2016

👍6

All 5 comments

tl;dr The main difference at this moment is that this one will actually work.

The swagger-codegen project only generates a client and even there it will only support flat models.

This project supports most features offered by jsonschema including polymorphism.
It allows for generating a swagger specification from go code.
It allows for generating a server from a swagger definition and to generate an equivalent spec back from that codebase.
It allows for generating a client from a swagger definition.
It has support for several common swagger vendor extensions.

Why is this not done in the swagger-codegen project? Because:

I don't really know java very well and so I'd be learning both java and the object model of the codegen which was in heavy flux as opposed to doing go and I really wanted to go experience of designing a large codebase with it.
Go's super limited type system makes it so that it doesn't fit well in the model of swagger-codegen
Go's idea of polymorphism doesn't reconcile very well with a solution designed for languages that actually have inheritance and so forth.
For supporting types like [][][]map[string][][]int64 I don't think it's possible with mustache
I gravely underestimated the amount of work that would be involved in making something useful out of it.
My personal mission: I want the jvm to go away, it was great way back when now it's just silly (vm in container on vm in vm in container)

casualjim on 7 Mar 2016

👍6

This explanation should definitely go to the first/landing page.