json-schema-spec
uplaybook
json-schema-spec | uplaybook | |
---|---|---|
29 | 5 | |
3,219 | 6 | |
2.9% | - | |
7.9 | 9.3 | |
10 days ago | about 1 month ago | |
JavaScript | Python | |
GNU General Public License v3.0 or later | Creative Commons Zero v1.0 Universal |
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.
json-schema-spec
-
TypeSpec: A New Language for API-Centric Development
Yep and that comes from JSON Schema: https://json-schema.org/
I believe recent versions of OpenAPI are "compatible" with JSON Schema (at least they "wanted to be" last I checked as I was implementing some schema converters).
Even TypeScript is not enough to represent all of JSON Schema! But it gets close (perhaps if you remove validation rules and stuff like that it's a full match).
But even something like Java can represent most of it pretty well, specially since sealed interfaces were added. I know because I've done it :).
- JSON Schema Blog
-
Deploy a simple data storage API with very little code using Amazon API Gateway and DynamoDB
models.tf where I centralized all the Data model that API Gateway uses to perform input and output checks. Those use the JSON-schema specification. GitHub - psantus/serverless.api-gateway-dynamodb-integration.terraform
- Unlocking the frontend – a call for standardizing component APIs pt.2
- JSON Schema
-
How to Automatically Consume RESTful APIs in Your Frontend
In the meantime, we are going to expand our backend with two endpoints: one for fetching data and another one for creating data. Fastify provides out-of-the-box support for API serialization and validation through its schema-based approach built on top of JSON Schema. Through the schema option, we can attach a schema definition to each route.
-
A View on Functional Software Architecture
JSON-schema to define templates for request and response contents.
-
Learn serverless on AWS step-by-step: Strong Types!
The syntax used to define the output is called JSON Schema. It is a standard way to define the structure of a JSON object. If you know zod, the spirit is similar. Based on Swarmion's roadmap, it will be possible to use zod schemas to defined contracts in the future, which will be super cool!
- XML is better than YAML
-
Function Calling: The Most Significant AI Feature Since ChatGPT Itself?
Essentially, all it does is attempt to generate the parameters to hypothetical or potential functions, which you using a JSON schema describe to ChatGPT.
uplaybook
-
Interesting Uses of Ansible's ternary filter
IMHO, the issue is that Ansible uses YAML to do "programming language" sorts of things, which is why it feels so unnatural.
I tried an experiment last year: What if Ansible had Python rather than YAML syntax. https://github.com/linsomniac/uplaybook?tab=readme-ov-file#s...
The downside is that having full Python available makes it really easy to make your playbooks non-idempotent, which Ansible gate-keeps behind Ansible modules. Also someone raised a concern that full Python (rather than a more limited safe dialect like Starlark) would make it harder to trust third-party playbooks. But considering uPlaybook's use case (ansible-like system configuration) it feels like even with a restricted dialect it is going to have plenty of opportunity for nefarious purposes.
I've put out uPlaybook for some limited review among my friends, and I've gotten some excitement about it. It doesn't have fleet management and remote running though, which is the big negative feedback I've gotten. I'm interested in thoughts on it though.
-
Why the fuck are we templating YAML? (2019)
Ansible convinced me that doing programming tasks in YAML is insanity, so I started an experiment: What would Ansible be like if it's syntax were more like Python than YAML. https://github.com/linsomniac/uplaybook
I spent around 3 months over the holidays exploring that by implementing a "micro Ansible", I have a pretty solid tool that implements it, but haven't had much "seat time" with it: working on it rather than in it. But what I've done has convinced me that there are some benefits.
-
Ask HN: Show me your half baked project
uPlaybook2: https://github.com/linsomniac/uplaybook2
This is a python-syntax re-imagining of Ansible / Cookiecutter: declarative IT automation and project templating. It's fairly early, but the heart of it is there: I'm able to create files/directories and render templates, running it displays status, I have most of the "magic" implemented that makes it less like Python and more like Ansible. The CLI entry-point is minimal, I need to basically forklift over the uPlaybook1 argument handling code and playbook search/selection.
Would love feedback from someone who is familiar with Python and Ansible about the direction of the YAML -> Python for playbook syntax, but I worry that it's too early to even give that.
Basically it's uPlaybook (v1) but with the Ansible-inspired YAML playbooks reimagined as Python: https://github.com/linsomniac/uplaybook
-
XML is better than YAML
Agreed, I do a lot of Ansible, and it took me a while up front, but I've become pretty accustomed to YAML. Though I still struggle with completely groking some of the syntax. But, I recently took a more serious look at TOML and felt like it'd be a bear for Ansible.
A few months ago I made a "mini ansible / cookie cutter" ( https://github.com/linsomniac/uplaybook ), and it uses YAML syntax. I made a few modifications to Ansible syntax, largely around conditionals and loops. For YAML, I guess I like the syntax, but I've been feeling like there's got to be a better way.
I kind of want a shell syntax, but with the ansible command semantics (declarative, --check / --diff, notify) and the templating and encryption of arguments / files.
-
Show HN: Trogon – An automatic TUI for command line apps
This is exactly my current experiment on a personal project I'm working on, though I'm trying to create a Textual UI on a dynamic Python argparse CLI. Creating a Textual UI is non-trivial.
My tool uPlaybook[0] is kind of a CookieCutter [1] / Ansible [2] mashup, and the playbooks typically would have a number of "slots" you can configure to control the templating, like project name, license, if you want to "git init", that sort of thing.
It currently auto-generates a argparse interface, or it can interactively ask you those questions. But I've been working on a Textual UI as well. I chose argparse over Click largely because I want to work with minimal dependencies, and the Textual UI would be an optional dependency.
Going to have to check this guy out.
[0] https://github.com/linsomniac/uplaybook
What are some alternatives?
outlines - Structured Text Generation
LGV_MeetingServer - An aggregation server for meeting list servers.
guidance - A guidance language for controlling large language models.
Octo - A Chip8 IDE
nix-configs - My Nix{OS} configuration files
ail-framework - AIL framework - Analysis Information Leak framework
OpenAPI-Specification - The OpenAPI Specification Repository
hsh - better shell
torch-grammar
ngs - Next Generation Shell (NGS)
ajv - The fastest JSON schema Validator. Supports JSON Schema draft-04/06/07/2019-09/2020-12 and JSON Type Definition (RFC8927)
NoSQL - A NoSQL implementation DBMS using LSM Trees