A metaprogramming technique like source-code generation is not a serious issue in any design. It's especially helpful if the source of truth in your design is external to the current code base. You can generate:
- documentation from source-code files, some CLI frameworks are offering this (eg. oclif[0])
- types from schema files, and schemas from types (eg. quicktype[1])
- API clients and servers from specifications (eg. openapi-generator[2])
...these are all repetitive tasks that can be automated.
That being said, I wouldn't personally generate it in the build step, but rather introduce an additional generate step for it and sync the generated output with the VCS of choice. I recently wrote about it a bit here[3].
[0]: https://github.com/oclif/oclif#oclif-readme
[1]: https://app.quicktype.io/
[2]: https://github.com/OpenAPITools/openapi-
OpenAPITools
openapi-generator
Java2018–2025
OpenAPITools / openapi-generator
openapi-generator
OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
43Distinct people
101Mentions
0Explicit recommenders
26.9KGitHub stars
What to know before exploring
What it is
OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
GitHub
Where it is used
No documented product use was verified in the last source check.
What people are saying
No recommendation phrase was found in the indexed comments.
No classified warning is attached to this page. Read the discussions before treating silence as approval.
Also in these discussions
- swagger-api/swagger-codegen · linked in 3 of the same discussions
- azure/autorest · linked in 2 of the same discussions
- go-swagger/go-swagger · linked in 2 of the same discussions
Mentioned in the same Hacker News threads. That is not proof they are substitutes.
This week on Hacker News
Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 7:02:50 PM UTC.
No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.
Mentions over time
HN mentions by year101 dated mentions
Observed mentions: 2018-06-02 02:49:00 UTC to 2025-11-24 00:55:21 UTC.
Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.
View mention counts and date ranges
| Period | Start (UTC) | End (exclusive, UTC) | Mentions | Submissions | Comments |
|---|---|---|---|---|---|
| 2018 | 2018-01-01 00:00:00 UTC | 2019-01-01 00:00:00 UTC | 10 | 5 | 5 |
| 2019 | 2019-01-01 00:00:00 UTC | 2020-01-01 00:00:00 UTC | 35 | 25 | 10 |
| 2020 | 2020-01-01 00:00:00 UTC | 2021-01-01 00:00:00 UTC | 15 | 6 | 9 |
| 2021 | 2021-01-01 00:00:00 UTC | 2022-01-01 00:00:00 UTC | 10 | 2 | 8 |
| 2022 | 2022-01-01 00:00:00 UTC | 2023-01-01 00:00:00 UTC | 12 | 4 | 8 |
| 2023 | 2023-01-01 00:00:00 UTC | 2024-01-01 00:00:00 UTC | 5 | 1 | 4 |
| 2024 | 2024-01-01 00:00:00 UTC | 2025-01-01 00:00:00 UTC | 10 | 2 | 8 |
| 2025 | 2025-01-01 00:00:00 UTC | 2026-01-01 00:00:00 UTC | 4 | 0 | 4 |
From the project README
An excerpt from the repository, fetched Nov 13, 2026.
Read the project’s introduction
OpenAPI Generator
Master (7.28.0):
⭐⭐⭐ If you would like to contribute, please refer to guidelines and a list of open tasks. ⭐⭐⭐
‼️ To migrate from Swagger Codegen to OpenAPI Generator, please refer to the migration guide ‼️
📔 For more information, please refer to the Wiki page and FAQ 📔
📔 The eBook A Beginner's Guide to Code Generation for REST APIs is a good starting point for beginners 📔
⚠️ If the OpenAPI spec, templates or any input (e.g. options, environment variables) is obtained from an untrusted source or environment, please make sure you've reviewed these inputs before using OpenAPI Generator to generate the API client, server stub or documentation to avoid potential security issues (e.g. code injection). For security vulnerabilities, please contact team@openapitools.org. ⚠️
‼️ Both "OpenAPI Tools" (https://OpenAPITools.org - the parent organization of OpenAPI Generator) and "OpenAPI Generator" are not affiliated with OpenAPI Initiative (OAI) ‼️
Sponsors
If you find OpenAPI Generator useful for work, please consider asking your company to support this Open Source project by becoming a sponsor. You can also individually sponsor the project by becoming a backer.
Thank you to our bronze sponsors!
Thank you GoDaddy for sponsoring the domain names, Linode for sponsoring the VPS, Checkly for sponsoring the API monitoring and Gradle for sponsoring Develocity
Overview
OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (both 2.0 and 3.0 are supported). Currently, the following languages/frameworks are supported:
Languages/Frameworks
API clients
ActionScript, Ada, Apex, Bash, C, C# (.net 2.0, 3.5 or later, .NET Standard 1.3 - 2.1, .NET Core 3.1, .NET 5.0. Libraries: RestSharp, GenericHost, HttpClient), C++ (Arduino, cpp-restsdk, Qt5, Tizen, Unreal Engine 4), Clojure, Crystal, Dart, Elixir, Elm, Eiffel, Erlang, Go, Groovy, Haskell (http-client, Servant), Java (Apache HttpClient 4.x, Apache HttpClient 5.x, Jersey2.x, OkHttp, Retrofit1.x, Retrofit2.x, Feign, RestTemplate, RESTEasy, Vertx, Google API Client Library for Java, Rest-assured, Spring 5 Web Client, Spring 6 RestClient, MicroProfile Rest Client, Helidon), Jetbrains HTTP Client, Julia, k6, Kotlin, Lua, N4JS, Nim, Node.js/JavaScript (ES5, ES6, AngularJS with Google Closure Compiler annotations, Flow types, Apollo GraphQL DataStore), Objective-C, OCaml, Perl, PHP, PowerShell, Python, R, Ruby, Rust (hyper, reqwest, rust-server), Scala (akka, http4s, scalaz, sttp, swagger-async-httpclient, pekko), Swift (2.x, 3.x, 4.x, 5.x, 6.x), Typescript (AngularJS, Angular (9.x - 19.x), Aurelia, Axios, Fetch, Inversify, jQuery, Nestjs, Node, redux-query, Rxjs), XoJo, Zapier
Server stubs
Ada, C# (ASP.NET Core, Azure Functions), C++ (Httplib, Oat++, Pistache, Restbed, Qt5 QHTTPEngine), Erlang, F# (Giraffe), Go (net/http, Gin, Echo), Haskell (Servant, Yesod), Java (MSF4J, Spring, Undertow, JAX-RS: CDI, CXF, Inflector, Jersey, RestEasy, Play Framework, PKMST, Vert.x, Apache Camel, Helidon), Julia, Kotlin (Spring Boot, Ktor, Vert.x), PHP (Flight, Laravel, Lumen, Mezzio (fka Zend Expressive), Slim, Silex, Symfony), Python (FastAPI, Flask), NodeJS, Ruby (Sinatra, Rails5), Rust (rust-server), Scala (Akka, Finch, Lagom, Play, Cask, Scalatra)
API documentation generators
HTML, Confluence Wiki, Asciidoc, Markdown, PlantUML
Configuration files
Apache2
Others
GraphQL, JMeter, Ktorm, MySQL Schema, Postman Collection, Protocol Buffer, WSDL
Table of contents
Sponsors
Thank you to our bronze sponsors!
Thank you GoDaddy for sponsoring the domain names, Linode for sponsoring the VPS, Checkly for sponsoring the API monitoring and Gradle for sponsoring Develocity
Overview
Table of contents
1 - Installation
1.1 - Compatibility
1.2 - Artifacts on Maven Central
1.3 - Download JAR
Launcher Script
1.4 - Build Projects
Nix users
1.5 - Homebrew
1.6 - Docker
Public Pre-built Docker images
OpenAPI Generator CLI Docker Image
OpenAPI Generator Online Docker Image
Development in docker
Troubleshooting
Run Docker in Vagrant
1.7 - NPM
1.8 - pip
2 - Getting Started
3 - Usage
To generate a sample client library
3.1 - Customization
3.2 - Workflow Integration (Maven, Gradle, Github, CI/CD)
3.3 - Online OpenAPI generator
3.4 - License information on Generated Code
3.5 - IDE Integration
4 - Companies/Projects using OpenAPI Generator
5 - Presentations/Videos/Tutorials/Books
6 - About Us
6.1 - OpenAPI Generator Core Team
Core Team Members
Template Creator
How to join the core team
6.2 - OpenAPI Generator Technical Committee
Members of Technical Committee
6.3 - History of OpenAPI Generator
Founding Members (alphabetical order):
7 - License
1 - Installation
1.1 - Compatibility
The OpenAPI Specification has undergone 3 revisions since initial creation in 2010. The openapi-generator project has the following compatibilities with the OpenAPI Specification:
OpenAPI Generator Version
Release Date
Notes
7.28.0 (upcoming minor release) SNAPSHOT
20.11.2026
Minor release with breaking changes (with fallback)
7.27.0 (latest stable release)
02.11.2026
Minor release with breaking changes (with fallback)
6.6.0
11.05.2023
Minor release with breaking changes (with fallback)
5.4.0
31.01.2022
Minor release with breaking changes (with fallback)
4.3.1
06.05.2020
Patch release (enhancements, bug fixes, etc)
OpenAPI Spec compatibility: 1.0, 1.1, 1.2, 2.0, 3.0, 3.1 (beta support)
(We do not publish daily/nightly build. Please use SNAPSHOT instead)
For old releases, please refer to the Release page.
For decommissioned generators/libraries/frameworks, please refer to the "Decommission" label in the pull request page.
1.2 - Artifacts on Maven Central
You can find our released artifacts on maven central:
Core:
<dependency>
<groupId>org.openapitools</groupId>
<artifactId>o
Read the full README on GitHubWhat Hacker News says
5 sourcesIn Cog: Use Python in your source files to generate pieces of code (2021)
I've tried using OpenAPI a few times, it's been...lackluster... I probably won't use it again.
Here are my gripes:
1) For me one of the biggest selling points is client code gen (https://github.com/OpenAPITools/openapi-generator). Basically it sucks, or at least it sucks in enough languages to spoil it. The value prop here is define the API once, code gen the client for Ruby, Python and Scala (or insert your languages here). Often there are a half dozen clients for each language, often they are simply broken (the generated code just straight up doesn't compile). Of the ones that do work, you get random PRs accepted that impose a completely different ideological approach to how the client works. It really seems like any PR is accepted with no overarching guidance.
2) JSONSchema is too limited. We use it for a lot of things, but it just mak
Read the rest
es some things incredibly hard. This is compounded by the seemingly limitless number of version or drafts of the spec. If your goal is interop, which it probably is if you are using JSON, you have to go our and research what the lower common denominator draft spec JSONSchema support is for the various languages you want to use and limit yourself to that (probably draft 4, or draft 7).
On the pros side:
It does make pretty docs - kinda wish it would just focus on this and in the process not be as strict, I think it would be a better project.
OpenAPI Generator v6.6.0 Released
2 points · Open discussion> I think once we get to the point where the design is so fixed for a set of standardised tasks like that, that we know how long it will take, the design is also so fixed that we can run a script that generates the code for it, so the time to make it is close to zero.
For all of the boilerplate stuff, I fully welcome and embrace it. For example, we already have codegen for various stacks, even Ruby on Rails: https://guides.rubyonrails.org/generators.html
Sadly, model driven development never really took off, because seemingly everyone was interested in being able to iterate and ship new features in frameworks quickly, as opposed to slowing down and working on different ways to interact with what's already there.
SOAP had WSDL, but REST needed a whole bunch of time until we got OpenAPI and levels of codegen that SoapUI had years ago: https
Read the rest
://github.com/OpenAPITools/openapi-generator
MySQL Workbench also has great bi-directional ER diagram support, with forward/backward engineering and schema sync: https://dev.mysql.com/doc/workbench/en/wb-design-engineering...
But maybe I'm asking for too much, generating templates for views with model fields, or even model bindings for the ORM is already good, as is generating DB migrations as well.
Used by:
- OpenAPI/Swagger (1), which is the industry standard for REST API. Used by Kubernetes among others for resource descriptions
- OpenRPC (json-rpc standard)
- Most YAML based configuration files.
GraphQL doesn't quite supersede JSONSchema because it doesn't deal with validation. (Something like Cue (https://cuelang.org/) might)
Type systems are not typically cross-language, which is where JSONSchema tends to be used a lot.
There are indeed a lot of openapi-based client generators. This one, for example, has been around for quite some time: https://github.com/OpenAPITools/openapi-generator
(1) Kinda. OpenAPI schema and JSONSchema are largely intersecting sets but there are bits in both that aren't present in the other.
In Ask HN: Do you use JSON Schema? Help us shape its future stability guarantees