Swagger Is Great, But...
Swagger Is Great, But...
Scala is great to use when integrating with Spring MVC or a Spring Boot application -- but here are some of its pitfalls and drawbacks.
Join the DZone community and get the full member experience.Join For Free
Atomist is your platform for self-service software delivery. Try it for free today!
Even better, the integration with Spring MVC is top notch. Configuring Swagger in a Spring Boot application is as simple as adding a dependency and adding an annotation (hint for the Swagger guys: provide an autoconfiguration for Spring Boot).
That being said, there are some things that really, really annoy me. See, Swagger is built using Scala. Which also means that if you want to use Swagger, you’ll be pulling the entire Scala runtime into your build. For a Spring Boot application just serving a basic Spring MVC REST service, this means the build goes from 15 Mb to 48 Mb. Urgh. Tripling my build size just to add documentation is enough for me to call it a day and throw it out of my build.
Another thing is that Swagger really doesn’t work in a microservices environment, at least not with Spring MVC. Swagger needs to be in the build with the REST controller, so this means you’ll be including Swagger into each and every microservice deployment (dragging the 33 Mb overhead everywhere you go) and you’ll have multiple Swagger JSON files. Double urgh. I have yet to find an aggregator that merges different Swagger JSON’s into a single one.
Of the 2 issues I have with Swagger, the size issue is the one I find the most annoying. I understand that it’s cool to use Scala but if using a library would mean my build grows 3 times in size I would think twice of using it, especially if it’s just for generating documentation. I personally think Swagger should be lean and mean. Just cutting Scala from the library would reduce the overhead by 20 Mb (I use Groovy rigorously and even then I don’t like the fact that it adds between 4 and 8 Mb to my build). But it’s also just POM sloppiness: pulling in mockito (should be a test library), 2 versions of cglib, JodaTime libraries (which for Java 8 users might not be desirable), … Some proper POM maintenance seems to be in order.
And as for the JSON aggregation, I don’t think it would take me too long to write something in JSON that reads the different JSON’s and aggregates them into a single one (which would also solve the nagging CORS issues you’d be having otherwise). Come to think of it, it would be great to make an aggregator to which applications can push their Swagger JSONs on startup. That way you would have some sort of automatic aggregated documentation that updates itself after each deployment and to which adding a microservice would be a breeze. Documentation as a service, I like it. Another day, another post, another idea.
Published at DZone with permission of Lieven Doclo , DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.