[Suggestion]: add Play Json support for Openapi spec

[jumale]

I use Play Json library in my project. Swagger (OpenAPI) supports both YAML and JSON formats for their spec files. Hence, I do not necessarily need to import Circe into my project, if there is a possibility to generate spec-files as JSON (instead of YAML) using predefined Play JSON encoders.

So I wanted to suggest to create a PR in https://github.com/softwaremill/sttp-apispec with a new sub-package openapi-play-json with Play JSON encoders for all the model-types. This way I could generate the Openapi spec in JSON format and remove the dependency on Circe.

~~But I've noticed that at the moment tapir-openapi-docs package in this repo depends on Circe, so even if drop/replace openapi-circe-yaml in my build.sbt - still it will be pulled as an indirect dependency.~~ ~~Although I could not find any imports of Circe in the scala code of tapir-openapi-docs - does this package really depends on Circe, or can it be dropped? If I guess correctly, it was probably added just for convenience, so that devs need to explicitly import one lib instead of two libs. If that's the case, then maybe we could create a new meta-package tapir-openapi-docs-circe which merges tapir-openapi-docs with openapi-circe-yaml. Or just mention in docs that two libs need to be installed.~~

[adamw]

The dependency in tapir-openapi-docs is:

"com.softwaremill.sttp.apispec" %% "openapi-circe-yaml" % Versions.sttpApispec % Test

so it's only for tests. Adding this dependency to your project shouldn't add circe as a dependency.

As for creating alternate play-json serialisers - that's of course possible, though I'm not sure if the additional maintenance costs justify adding a new module. Using circe for encoding is mostly an implementation detail of the openapi module - does it cause you any problems to have circe added there?

[jumale]

Ah, my apologies, I missed the test part. Then everything is all right.

though I'm not sure if the additional maintenance costs justify adding a new module

I understand. In general I planned to add those encoders locally in my project, but then I thought maybe other people would be also interested in it. Then probably I will create it locally for now, and later consider publishing it as a separated repo.

does it cause you any problems to have circe added there?

no, it's very minor, I was just analysing my deps tree, and noticed that there are 9 circe-related libraries, and they are all in the top part of the list sorted by heaviest size, and it's just sad to see this picture considering that I don't even directly use it

[info]  15,544 MB   0,005 MB   17    2 com.softwaremill.sttp.apispec:openapi-circe-yaml_2.13:0.7.2
[info]  15,111 MB   0,297 MB   13    2 com.softwaremill.sttp.apispec:openapi-circe_2.13:0.7.2
[info]  14,619 MB   0,056 MB   11    5 com.softwaremill.sttp.apispec:jsonschema-circe_2.13:0.7.2
[info]  14,340 MB   0,175 MB    5    2 io.circe:circe-generic_2.13:0.14.6
[info]  11,348 MB   0,072 MB    6    2 io.circe:circe-yaml_2.13:1.15.0
[info]  11,044 MB   0,003 MB    6    2 io.circe:circe-parser_2.13:0.14.6
[info]  11,041 MB   0,031 MB    5    2 io.circe:circe-jawn_2.13:0.14.6
[info]  10,942 MB   0,021 MB    4    1 io.circe:circe-yaml-common_2.13:1.15.0
[info]  10,921 MB   1,160 MB    3    2 io.circe:circe-core_2.13:0.14.6

And they're all coming from the "com.softwaremill.sttp.apispec" %% "openapi-circe-yaml" dependency. So if I drop it, and replace it with custom Play JSON formatters (which is just around 300 lines of code) - then all 9 are gone from the tree.

[adamw]

I see, thanks for the explanation :) Let's keep this issue open, if more people would like this to happen then we'll add the module.

[kciesielski]

@jumale could you change the issue title to reflect that it's about adding a new module?