I continue to proselytize the virtues of knowing your stack in order to avoid careless integration.Going back to swagger; it's written in java and while that's not a very big deal there are the mixed signals from Oracle depending on who you follow and the news you read (FUD). But then there is also the embedded crud-ware that Oracle includes in the installers. You cannot just install Java and go. Of course there are 3rd party JDKs but then you have to validate which JVMs are supported/tested on which app; and so version creep begins. And that can be offset with containers like rkt and docker.
The amount of wrapping is starting to get pretty thick. Each layer requires expert knowledge. Each layer requires regression and readiness testing.And then there is the question of real value. swagger's value proposition is it's code generation and it's GUI. There are several parts to the code generation and it depends on your perspective. Swagger's code is generated from a spec file. There is nothing special about the spec but the generator will generate client stubs for the defined API.
This is interesting in that the client stubs can be generated with version consistency with the spec file so long as the file is kept consistent with the server side APIs. And that's the rub. Where is the server side in all of this? The amount of work required to keep the spec file should be minimal and a product of some other compilation step.
code generation should be a one to many operation. Having some defined API method a generator should be able to identify the APIs, generate the API entry point and the client stub. (sourcegraph has some interesting go tools in this space)Your 10x programmer and your super-polyglot will drown if they get tripped up in menial tasks. It's the wrong problem for the wrong person. I'm also trying to say that if you know your tools you should not have to use this sort of tool.