Open cchafer opened 3 years ago
@cchafer thanks for starting a discussion on this and sharing various proposals.
My understanding is that there's no (or just minimal) demand to support multiple JSON marshallers at the moment in the Scala akka server generator. Please correct me if I'm wrong.
Ideally proposal 3 can meet everyone's requirement but it requires a lot more resources due to its complexity as you've pointed out.
My suggestion is to go with proposal 2 to start with and start collecting feedback from the users.
Some generators (e.g. Java, C# client generators) support different HTTP libraries via the --library
option thanks to the swappable ApiClient
mustache file. Maybe we can do something similar to make the JSON marshaller file swappable. Just a suggestion :)
You are right, currently there is no real demand for multiple json marshallers. But that's mostly because there is no basic implementation, so in the end, nobody is blocked.
So I would propose a mix of solution 2 and 3: choose a json library that will be used by default, and have a --library option that allows to change, and that will allow other contributors to improve the generator if the default library does not suit them.
For json library, please use the option serializationLibrary
instead (forgot to mention in my previous reply). --library
is for HTTP library
Problem
Akka stub servers, and more generally scala stubs, can rely on a multitude of Json parsers. Two approaches are therefore possible when generating projects via openapi: either choose one, or let the user choose his own, by just providing an interface (which is the case in scala-akka-http-server).
Each solution has its advantages and disadvantages. Choosing for the user will often mean having unnecessary dependencies (why have spray-json when I already have jackson?). On the other hand, having a totally generic stub leads to generate files that are not directly usable. A whole layer of serialization has to be added by the user, which makes the use of the akka-http module more complex.
Proposal 1
No change in current behavior. Users of scala-akka-http have to guess how to use the generated code.
Pros:
Cons:
Proposal 2
We generate code with a predefined Json dependency. Pros :
Cons:
Proposal 3
We generate the same code as now, but with an option to generate marshallers. This option could allow to specify the json backend to use, free afterwards to make PR to add the backend of his choice.
Pros:
Cons:
Conclusion
As a commiter and user of this generator, I would like it to be as useful to others as it is to me, so I am willing to modify it to best fit the expectations and policy of the project.
Looking forward to reading your feedbacks, comments, desires, criticisms, thank you!