# SSWG-0026: Swift OpenAPI Generator **URL:** \ **Category:** Proposals\ **Created:** [September 7, 2023, 8:13am UTC](https://forums.swift.org/t/sswg-0026-swift-openapi-generator/67164 "2023-09-07T08:13:16Z")\ **Posts on this page:** 9\ **Page:** 1
**Author:** ![Joannis\_Orlandos](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joannis_orlandos/32/732_2.png) [@Joannis\_Orlandos](https://forums.swift.org/u/Joannis_Orlandos)\ **Post date:** [September 7, 2023, 8:13am UTC](https://forums.swift.org/t/sswg-0026-swift-openapi-generator/67164/1 "2023-09-07T08:13:16Z")
The review of [SSWG-0026: Swift OpenAPI Generator](https://github.com/swift-server/sswg/blob/main/proposals/0026-swift-openapi-generator.md) begins now and runs for two weeks, until September 21st, 2023. * * * Reviews are an important part of the Swift Server Work Group [incubation process](https://www.swift.org/sswg/incubation-process.html). 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](mailto:joannis@orlandos.nl)) or direct message in the Swift forums. The package is being proposed at the **Sandbox** maturity level. Please note the Maturity Justification inside the proposal for details. The previous pitch thread is here: [Swift OpenAPI Generator](https://forums.swift.org/t/pitch-sswg-incubation-swift-openapi-generator/66584) * * * ## What goes into a review of a proposal? 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](https://www.swift.org/sswg/#projects). 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? Joannis Orlandos The Review Manager ---
**Author:** ![FranzBusch](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/franzbusch/32/19447_2.png) [@FranzBusch](https://forums.swift.org/u/FranzBusch)\ **Post date:** [September 7, 2023, 2:53pm UTC](https://forums.swift.org/t/sswg-0026-swift-openapi-generator/67164/2 "2023-09-07T14:53:57Z")
- 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. ---
**Author:** ![JuneBash](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/junebash/32/19323_2.png) [@JuneBash](https://forums.swift.org/u/JuneBash)\ **Post date:** [September 7, 2023, 3:49pm UTC](https://forums.swift.org/t/sswg-0026-swift-openapi-generator/67164/3 "2023-09-07T15:49:47Z")
> - 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. ---
**Author:** ![Honza\_Dvorsky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/honza_dvorsky/32/29867_2.png) [@Honza\_Dvorsky](https://forums.swift.org/u/Honza_Dvorsky)\ **Post date:** [September 7, 2023, 5:12pm UTC](https://forums.swift.org/t/sswg-0026-swift-openapi-generator/67164/4 "2023-09-07T17:12:53Z")
> [@JuneBash](#): > > 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`. 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. A guide for this is documented here: [swift-openapi-generator Documentation – Swift Package Index](https://swiftpackageindex.com/apple/swift-openapi-generator/0.2.1/documentation/swift-openapi-generator/api-stability-of-generated-code#Create-a-curated-client-library-package) ---
**Author:** ![JuneBash](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/junebash/32/19323_2.png) [@JuneBash](https://forums.swift.org/u/JuneBash)\ **Post date:** [September 8, 2023, 5:22pm UTC](https://forums.swift.org/t/sswg-0026-swift-openapi-generator/67164/5 "2023-09-08T17:22:54Z")
> [@Honza\_Dvorsky](#): > > 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. I guess I would personally prefer not to add another module to the project, which is why I'd love the option of configuring this. ---
**Author:** ![taylorswift](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/taylorswift/32/43413_2.png) [@taylorswift](https://forums.swift.org/u/taylorswift)\ **Post date:** [September 9, 2023, 4:35am UTC](https://forums.swift.org/t/sswg-0026-swift-openapi-generator/67164/6 "2023-09-09T04:35:25Z")
> [@Honza\_Dvorsky](#): > > 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. does this interfere with code size optimizations? ---
**Author:** ![Honza\_Dvorsky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/honza_dvorsky/32/29867_2.png) [@Honza\_Dvorsky](https://forums.swift.org/u/Honza_Dvorsky)\ **Post date:** [September 9, 2023, 6:18am UTC](https://forums.swift.org/t/sswg-0026-swift-openapi-generator/67164/7 "2023-09-09T06:18:58Z")
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](https://swiftpackageindex.com/apple/swift-openapi-generator/0.2.1/documentation/swift-openapi-generator/api-stability-of-generated-code)). ---
**Author:** ![Joannis\_Orlandos](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/joannis_orlandos/32/732_2.png) [@Joannis\_Orlandos](https://forums.swift.org/u/Joannis_Orlandos)\ **Post date:** [October 4, 2023, 1:04pm UTC](https://forums.swift.org/t/sswg-0026-swift-openapi-generator/67164/8 "2023-10-04T13:04:24Z")
Hello everyone! The SSWG has decided to **accept this proposal** into **Sandbox** maturity level! 🎉 The project fulfils all requirements of the [Sandbox](https://github.com/swift-server/sswg/blob/master/process/incubation.md#sandbox-level) level, including multiple maintainers and an active stream of development, good CI and adoption of concurrency features. We'll add the project to the list of SSWG endorsed projects shortly. ---
**Author:** ![Honza\_Dvorsky](https://sea2.discourse-cdn.com/swift/user_avatar/forums.swift.org/honza_dvorsky/32/29867_2.png) [@Honza\_Dvorsky](https://forums.swift.org/u/Honza_Dvorsky)\ **Post date:** [November 27, 2023, 12:35pm UTC](https://forums.swift.org/t/sswg-0026-swift-openapi-generator/67164/9 "2023-11-27T12:35:30Z")
> [@JuneBash](#): > > However, it would be great if we could have more configuration options in terms of how the APIs are generated. Hi @JuneBash, we're adding this feature for 1.0, you'll be able to choose from `public`, `package` (the new default), and `internal`. > > > \### Motivation > > Fixes #270. > > The \`package\` access modifier seems like the right …default access modifier for generated code, as it forces adopters to explicitly opt into generated APIs leaking outside of their package. \`internal\` was too limiting, as often you want to isolate generated code into a separate module. Fortunately, Swift 5.9 provided that feature and since 1.0 will ship with 5.9 as minimum Swift version, we can switch to \`package\` as default. > > \### Modifications > > \- (Re)added the ability to customize the access modifier of the generated code. You can do so from the config file and with a CLI option. > \- The default has changed from \`public\` to \`package\` (a breaking change). > \- Updated docs (some drive-by docs improvements as well for which OpenAPI features are supported.) > > \### Result > > Generated code uses the \`package\` access modifier by default, but the user can change it to \`public\` or \`internal\`, if needed. > > \### Test Plan > > Manually tested the CLI path, the config file path, updated tests, but didn't actually change our fixtures, as there's no need. We just explicitly override to \`public\`. > > I also tried this branch on a real-world document using the generator plugin, and tried all 3 access modifiers and verified all 3 worked (the project built successfully).