Reviews are an important part of the Swift Server Work Group incubation process. All review feedback should be either on this forum thread or, if you would like to keep your feedback private, directly to the review manager (via email) or direct message in the Swift forums.
The package is being proposed in either the Sandbox maturity level. Please note the Maturity Justification inside the proposal for details.
The goal of the review process is to improve the proposal under review through constructive criticism and, eventually, become listed on the Swift Server Ecosystem index page.
When reviewing a proposal, here are some questions to consider:
What is your evaluation of the proposal and its APIs/implementation?
Is the problem being addressed relevant for the wider Swift on Server ecosystem?
Does this proposal fit well with the feel and direction of the Swift Server ecosystem?
If you have used other libraries in Swift or other languages, how do you feel that this proposal compares to those?
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
What is your evaluation of the proposal and its APIs/implementation?
+1 from me. The APIs have been very well thought out.
Is the problem being addressed relevant for the wider Swift on Server ecosystem?
OpenAPI is an important tool to define APIs and removes a bunch of error classes when interacting between client and server.
Does this proposal fit well with the feel and direction of the Swift Server ecosystem?
Yes 100%. It fully embraces Concurrency and provides modern APIs.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
I read the proposal and reviewed the implementation in depth.
What is your evaluation of the proposal and its APIs/implementation?
+0.9. I'm using the URLSession adapter in an app right now, and for the most part it's working wonderfully and saving us quite a bit of time.
However, it would be great if we could have more configuration options in terms of how the APIs are generated. The endpoint IDs in our OpenAPI spec use snake case, which ends up looking very ugly and non-idiomatic in the generated code, but works well for them on the server side. This means we end up having to write a translation layer of types and functions and whatnot over top of the generated code. It'd therefore be nice if we could also have the option to keep the generated code internal-only rather than it having to be public.
(To be clear, as a first pass, overall, I'm very supportive of this package existing.)
Is the problem being addressed relevant for the wider Swift on Server ecosystem?
Absolutely.
Does this proposal fit well with the feel and direction of the Swift Server ecosystem?
I believe so, though admittedly I haven't spent a ton of time with the rest of the ecosystem.
If you have used other libraries in Swift or other languages, how do you feel that this proposal compares to those?
Again, more configuration options would be nice, though I imagine this is more of a "Future Directions" issue.
How much effort did you put into your review? A glance, a quick reading, or an in-depth study?
As mentioned, I am currently using this package in production, but in terms of this review I only spent a few minutes on it.
You can generate your code into a dedicated module, and then import that module from your public module, giving you full control over what's public. That's why we don't have an option to generate the code as internal.
If binary size is a concern, please file an issue on the repo and we can discuss there.
// Edit: My expectation is that when building an executable, the Swift compiler has enough information to strip all the unused generated methods and types, even cross-modules, at link time. And if you're building a library for distribution, code size could be another reason to not leak the generated code into your public API, so that again, the compiler could remove all the generated code that you're not using as part of the library's implementation. (The reason we discourage publishing generated code as API is documented here: swift-openapi-generator Documentation – Swift Package Index).