What does HackerNews think of openapi-generator?
OpenAPI Generator allows generation of API client libraries (SDK generation), server stubs, documentation and configuration automatically given an OpenAPI Spec (v2, v3)
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://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.
- 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.
https://github.com/OpenAPITools/openapi-generator
I chuckle every time I read claims about Go (or whatever) being amazingly productive. I don't think it's possible to beat this stack with regards to both productivity and ease of long-term support, at least without going to very niche technologies where you'll have other problems.
Database schema is generated from models described in C# (or reverse-engineered from an existing schema). You don't have to compromise your schema to satisfy the ORM (another claim I often read on HN), as it's very adaptable to your needs.
Migrations are generated automatically — change your models, ask it to generate migration code in C# + a SQL migration script, review the generated SQL, and apply.
The vast majority of database queries (pretty much everything besides reports) is written in type-safe LINQ, which makes it easy to refactor code, and also construct & combine queries at runtime. Unlike that specification abomination JPA expects you to use, LINQ queries look something like this:
var latestOrders = _db.Orders
.Where(ord => ord.CreatedAt >= DateTime.Today)
.Where(ord => !ord.Deleted)
.OrderByDescending(ord => ord.CreatedAt)
.Take(25)
.Select(ord => new {
OrderId = ord.Id,
Customer = ord.Customer.Name,
CreatedAt = ord.CreatedAt,
Products = ord.Products.Select(prod => new {
ProductId = prod.Id,
Title = prod.Title,
})
})
.ToList();
https://dev.to/danielgtaylor/a-cli-for-rest-apis-part-1-104b https://github.com/danielgtaylor/restish https://github.com/danielgtaylor/openapi-cli-generator https://github.com/OpenAPITools/openapi-generator
I recently learned about OpenAPI generator [1], which uses a spec-first approach to generate boilerplate for several frameworks, including Flask and FastAPI.
I would like to build or find a no code / visual tool that lets you build a JSON Schema file, and then generates boilerplate for you. I want to move on from rigid cookiecutter tools that make you go through 15 or so steps and force you to start over if you make the tiniest mistake.