Posted by k42b3 10/24/2024
1) They do not publish rationale of why the world needs yet another protocol / language / framework on the homepage. It is hidden in https://typeschema.org/history
2) In the history page, they confuse strongly typed and statically typed languages. I have a prejudice about people doing this.
3) The biggest challenge about data models is not auto-generated code (that many people would avoid in principle anyway), but compressed, optimized wire serialization. So you START with selecting this for your application (eg. AVRO, CapnProto, MessagePack etc) and then use the schema definition language coming with the serialization tool you've chosen.
Auto generated code is 100% enough, sometimes.
Any pointers?
(Serious question).
Agreed.
> 3) The biggest challenge about data models is not auto-generated code
I would say auto-generated code is most definitely the harder problem to solve, and I’d also go out on a limb and say it is THE problem to solve.
Whether it’s JSON, XML, JavaScript, SQL, or what have you, integrating both data and behavior between languages is paramount. But nothing has changed in the last 40+ years solving this problem, we still generate code the same clumsy way… Chinese wall between systems, separate build steps, and all the problems that go with it.
Something like project manifold[1] for the jvm world is in my view the way forward. Shrug.
They are also strict of cause
It has non-nullable types, via option, which makes non-nullable the default, since you have to explicitly wrap it in option. https://component-model.bytecodealliance.org/design/wit.html...
A way to represent types commonly found in major languages would be nice, but it would be better to start with something like wit and build on top of it, or at least have a lot of overlap with it.
So it could be typescript, Go, GraphQL, etc. It seems to output to JSON schema as well. I guess its main purpose is to share the schema between different languages. Which I imagine works with JSON schema too, but this takes it a step further and handle all the mapping you'd need to do otherwise.
typeschema in contrast seems to focus on describing just the structure of data with the goal to generate stubs in a wide variety of programming languages.
Seems a bit naively implemented.
Ideally, the duplicated props in Student would just be a single line of `Human`.
It seems to me like a mischaracterization of JSON Schema to say you can't define a concrete type without actual data.
I am a very stupid individual so I could be misunderstanding the argument.
The thought I do get: JSON Schema primarily describes one main document (object/thing). And additionally defines named types (#/definitions/Student). But it's totally fine to just use the definitions for code generation.
The reference semantics of JSON Schema is quite powerful, a little bit like XML with XSD and all the different imports and addons.
The moment you have types referencing other types in a way that can become recursive in ANY way, the whole thing seems to explode.
The TypeSchema spec is hard to comprehend as it doesn't delve into any details and looks like just a bunch of random examples with comments than a proper definitive document (e.g. they don't ever seem to define what "date-time" string format is). I don't see a way to say, e.g., that a string must be an UUIDv7, or that an integer must be non-negative, or support for heterogeneous collections, etc etc.
Maybe it has some uses for code generation across multiple languages for very simple JSON structures, but that feels like a very niche use case. And even then, if you have to hook up per-language validation logic anyway (and probably language-specific patterns too, to express concepts idiomatically), what's the point of a code generator?
They have more details on the History page.
At best, I can guess that maybe they are trying to get at the fact that JSON schema supports some structures that can be awkward or unidiomatic for data models in some languages (a lot of what you can do via allOf or oneOf fits this) and they want to narrow down to something where what can be defined in the schema language is also simple idiomatic structures nearly everywhere, but a restricted profile of JSON Schema would get you there much faster than starting from the ground up.
It feels more like a lowest common denominator to me, which is frequently (in presence of anything non-trivial) the opposite of idiomatic.
For example, JSON does not have monetary/decimal type, best option available is a string. It would be very opposite of idiomatic to have a C# or Python code use a string in the record/dataclass, instead of a decimal, if the actual JSON document field has the "monetary value" semantic.
And TypeSchema seem to ignore aspects like nullability and presence requirements, making assumptions that everything can be null (which can be wrong and even harmful, as if Java haven't taught us anything).
Maybe I'm thinking wrong about it and the idea is to have separate wire and public API formats, though, where the wire format is minimal JSON (TypeSchema can work, I guess, although I still have concerns about nulls - and distinguishing between nulls and absence of the field) and then that intermediate almost-over-the-wire-but-deserialized-from-JSON-blob object representation is adapted into a language-specific idiomatic structure. I always felt that such approach is way too verbose and adds a lot of boilerplate without a good reason, but I could be wrong about it.
I would've understood if it would do the inverse - read source code in any of the supported languages, and check if the structures it define it conforms to the schema. That would make sense for testing that those structs aren't too diverging between codebases (have the same-shaped fields). Even then I'm not sure I see the point because various languages tend to use different language-specific things (like an UUID type or enums/symbols/atoms, etc.) to make developer feel at home rather than in a barren JSONland.
Good effort though.
Edit: Oh I thought it was yours. Well I'll leave this up anyway.
use serde::{Serialize, Deserialize}; #[derive(Serialize, Deserialize)] pub struct Map { #[serde(rename = "totalResults")] total_results: Option<u64>,
#[serde(rename = "entries")]
entries: Option<Vec<T>>,
}