speakeasy
datamodel-code-generator
speakeasy | datamodel-code-generator | |
---|---|---|
7 | 9 | |
140 | 2,302 | |
13.6% | - | |
9.8 | 9.4 | |
2 days ago | 7 days ago | |
Go | Python | |
GNU General Public License v3.0 or later | MIT License |
Stars - the number of stars that a project has on GitHub. Growth - month over month growth in stars.
Activity is a relative number indicating how actively a project is being developed. Recent commits have higher weight than older ones.
For example, an activity of 9.0 indicates that a project is amongst the top 10% of the most actively developed projects that we are tracking.
speakeasy
-
Generating Code Without Generating Technical Debt?
I’ve built conviction that code generation only gets useful in the long term when it is entirely deterministic, or filtered through humans. Otherwise it is almost always technical debt. Hence LLM code generation products are a cool toy, but no sensible teams will use them without an amazing “Day 2” workflow.
As an example, in my day job (https://speakeasyapi.dev), we sell code generation products using the OpenAPI specification to generate downstream artefacts (language SDKs, terraform providers, markdown documentation). The determinism makes it useful — API updates propagate continuously from server code, to specifications, then to the SDKs / providers / docs site. There are no breaking changes because the pipeline is deterministic and humans are in control of the API at the start. The code generation itself is just a means to an end : removing boilerplate effort and language differences by driving it from a source of truth (server api routes/types). Continuously generated, it is not debt.
We’ve put a lot of effort into trying to make an LLM agent useful in this context. However giving them control of generated code directly means it’s hard to keep the “no breaking changes”, and “consistency” restrictions that’s needed to make code generation useful.
The trick we’ve landed on to get utility out of an LLM in a code generation task, is to restrict it to manipulating a strictly typed interface document, such that it can only do non-breaking things to code (e.g. adjust comments / descriptions / examples) by making changes through this interface.
- Show HN: OpenAPI to Terraform Provider Code Generation
-
HashiCorp silently amend Terraform Registry TOS
In my mind the analagous behaviour would be if the golang checksum database added in license terms that stated "you need to abide by a BSL to use data from this service". What that actually would mean is so nebulous that it feels threatening.
[0] Source: https://registry.terraform.io/v1/providers/airbytehq/airbyte...
[1] Source: https://github.com/airbytehq/terraform-provider-airbyte/tree... gzipped : ~300 resources, ~300 data sources
(NB: in airbyte's case the TF Provider was generated from a ~150Kb OpenAPI spec via https://speakeasyapi.dev: implying docs could be compressed even more)
-
OpenAPI v4 Proposal
I'm working on a company https://speakeasyapi.dev/ with the goal helping companies in this ecosystem get great production quality client sdks, terraform providers, cli(s) and all the developer surfaces you may want supported for our API. We also manage the spec and publishing workflow for you so all you have to do is build your API and we'll do the rest.
Feel free to email me at [email protected] or join our slack (https://join.slack.com/t/speakeasy-dev/shared_invite/zt-1cwb...) . We're in open beta and working with a few great companies already and we'd be happy for you to try out the platform for free!
-
Idiomatic Golang Client SDK Generation for OpenAPI APIs
Hi all I am a founding engineer for a API Experience company called Speakeasy - speakeasyapi.dev and we have recently released a Client SDK Generator for APIs using OpenAPI 3.0.X documents (soon to support 3.1). The generator will generate idiomatic Golang SDKs (along with other languages) that feel natural to use, easy to mock, and just work. The generator is free to use and can be run via a standalone golang built CLI with no external dependencies that can be easily installed as a binary or via homebrew (mac & linux). Check it out here https://github.com/speakeasy-api/speakeasy. If you have any questions or want to get in touch to see how Speakeasy can help you improve your APIs, just let me know!
-
Idiomatic SDKs for OpenAPI
The generator has been battle tested on thousands of APIs and we are sharing the results in our github repo. If you want to try it out on your own, download the CLI or brew install and get started in minutes:
datamodel-code-generator
- Datamodel-code-generator: Pydantic model/dataclass from OpenAPI, JSON, YAML
-
tRPC – Move Fast and Break Nothing. End-to-end typesafe APIs made easy
Like generating pydantic models or dataclasses for an OpenAPI schema? I haven't needed to go in that direction myself, but this[0] looks promising!
Apologies if I've misunderstood your comment
https://koxudaxi.github.io/datamodel-code-generator/
-
OpenAPI v4 Proposal
I'm sorry, but you have completely misunderstood the purpose of Open API.
It is not a specification to define your business logic classes and objects -- either client or server side. Its goal is to define the interface of an API, and to provide a single source of truth that requests and responses can be validated against. It contains everything you need to know to make requests to an API; code generation is nice to have (and I use it myself, but mainly on the server side, for routing and validation), but not something required or expected from OpenAPI
For what it's worth, my personal preferred workflow to build an API is as follows:
1. Build the OpenAPI spec first. A smaller spec could easily be done by hand, but I prefer using a design tool like Stoplight [0]; it has the best Web-based OpenAPI (and JSON Schema) editor I have encountered, and integrates with git nearly flawlessly.
2. Use an automated tool to generate the API code implementation. Again, a static generation tool such as datamodel-code-generator [1] (which generates Pydantic models) would suffice, but for Python I prefer the dynamic request routing and validation provided by pyapi-server [2].
3. Finally, I use automated testing tools such as schemathesis [3] to test the implementation against the specification.
[0] https://stoplight.io/
[1] https://koxudaxi.github.io/datamodel-code-generator/
[2] https://pyapi-server.readthedocs.io
[3] https://schemathesis.readthedocs.io
-
Create Pydantic datamodel from huge JSON file with local datamodel-code-generator
The site also provide a link to the github repo of the underlying program.
-
PSA: I think this JSON to Pydantic converter is extremely useful for boilerplate model creation
Not sure who owns/hosts the site, but its based on this github repo.
-
My top python library
That's what datamodel-code-generator propose.
-
I use attrs instead of pydantic
had generally good experience creating typed wrappers for api's with json-schema-to-pydantic[0] converter
[0] https://github.com/koxudaxi/datamodel-code-generator
-
What's the best libraries to build a REST API with Openapi compatibility
To save you some work, if you have already an OpenAPI specification at hand, you can use datamodel-code-generator to generate your Pydantic models from the spec.
-
This is what I pushed today, I don't know why but I was very positive about the code until someone reviewed it and pointed out the obvious. Also 'internal_data' field is very essential for other parts of the code. It is so embarrassing I want to disappear from the face of the earth.
And there are code generators for it! https://github.com/koxudaxi/datamodel-code-generator/
What are some alternatives?
fern - 🌿 Stripe-level SDKs and Docs for your API
sqlmodel - SQL databases in Python, designed for simplicity, compatibility, and robustness.
openapi-codegen - A tool for generating code base on an OpenAPI schema.
pydantic - Data validation using Python type hints
terraform-provider-stateful - Generic abstract stateful resources to manage arbitrary objects by executing arbitrary commands
pydantic-factories - Simple and powerful mock data generation using pydantic or dataclasses
taxilang - Taxi is a language for describing APIs, data models, and how everything relates
fastapi - FastAPI framework, high performance, easy to learn, fast to code, ready for production
para - Para - community plugin manager and a "swiss army knife" for Terraform/Terragrunt - just 1 tool to facilitate all your workflows.
odmantic - Sync and Async ODM (Object Document Mapper) for MongoDB based on python type hints
oatx - Generator-less JSONSchema types straight from OpenAPI spec
cattrs - Composable custom class converters for attrs.