RapidJSON and JSON Schema

[jviotti]

Hey there! I'm a TSC member of JSON Schema focused on building better and faster JSON Schema utilities for C++.

I saw this repo makes use of RapidJSON and its (limited) JSON Schema implementation. How is your use of RapidJSON going? Anything you like or dislike? Did you find a need for supporting newer dialects of JSON Schema than Draft 4?

Any honest feedback would be super appreciated to make JSON Schema and my C++ efforts in there more valuable! 🙏🏻

[BenPope]

@jviotti For validating and otherwise delving into JSON Schema we've primarily switched to using jsoncons

Most of the code that validates user-provided JSON Schema lives in here: https://github.com/redpanda-data/redpanda/blob/dev/src/v/pandaproxy/schema_registry/json.cc

[jviotti]

Hi @BenPope , thanks for the detailed information. I was not aware of jsoncons are we are not tracking it in https://bowtie.report to rank its level of compliance. I'll bring this up and see if we can get it added there.

Would it be interesting(and what would it take?) to use a JSON Schema validator directly supported by the JSON Schema TSC to guarantee top compliance and support? For C++, its currently JSON Toolkit (primarily written by myself), with a perfect compliance score on Bowtie, and support for Draft 4 all the way to 2020-12.

As an aside, how is jsoncons performance to you? The main reason I'm asking is that there is a lot of work to make JSON Toolkit the fastest JSON Schema evaluator out there, with benchmarks that will be eventually published on a paper soon. See https://github.com/sourcemeta-research/jsonschema-benchmark/actions/runs/11196179442 for the current state of it. So far we are the fastest one in all tested cases, often by orders of magnitude (often providing single instance validation at the nano-second range on decent hardware). I'll get jsoncons there and generally curious if speed is of any concern/benefit to Red Panda.

Thanks!

[BenPope]

Would it be interesting(and what would it take?)

AGPL 3 is a showstopper, so we'd have to investigate the commercial license.

As an aside, how is jsoncons performance to you?

In general performance is important, but most of what we use jsoncons for is not on the hot path, so we haven't compared performance.

One thing that would be particularly important is having control over the memory layout, in particular, being able to parse from and returns strings that are based on iterators that do not conform to std::contiguous_iterator.

We also need to avoid std::thread and related concepts such as std::mutex, and we'd also like to avoid std::shared_ptr.

[jviotti]

AGPL 3 is a showstopper, so we'd have to investigate the commercial license.

Red Panda licensing approach seems very similar to how we operate (to ensure our efforts are sustainable). That said, not sure if you would benefit from it given ultra fast JSON Schema validation is not your concern (which is our main selling point!).

The idea of the AGPL is to make it totally free for open-source, and given Red Panda is source available, then maybe there is a way to make it work. We were also evaluating giving out all JSON components except the ultra fast validator under more permissive licenses, so would love to know all your JSON requirements and nice-to-have, and see if we could make them happen.

In general performance is important, but most of what we use jsoncons for is not on the hot path, so we haven't compared performance.

How is jsoncons used, if I may ask? Is it validating every incoming request?

One thing that would be particularly important is having control over the memory layout, in particular, being able to parse from and returns strings that are based on iterators that do not conform to std::contiguous_iterator.

Ah, very interesting. I guess this is more on the JSON side. Do you mind elaborating more on the use case? Sounds fun, but not sure I can think of why its useful.

Right now, our JSON parser is purely based on standard streams, so I guess you could write an input stream that adheres to the interface and just gets characters in any way irrespective of memory continuity.

We also need to avoid std::thread and related concepts such as std::mutex, and we'd also like to avoid std::shared_ptr.

Good to know. We don't use any of it!

[BenPope]

How is jsoncons used, if I may ask? Is it validating every incoming request?

Not currently; it's used for schema versioning, and checking that one schema is compatible with another (e.g., forward or backward compatible), which are not on the hot data path.

One thing that would be particularly important is having control over the memory layout, in particular, being able to parse from and returns strings that are based on iterators that do not conform to std::contiguous_iterator.

Ah, very interesting. I guess this is more on the JSON side. Do you mind elaborating more on the use case? Sounds fun, but not sure I can think of why its useful.

Right now, our JSON parser is purely based on standard streams, so I guess you could write an input stream that adheres to the interface and just gets characters in any way irrespective of memory continuity.

For example, RapidJSON can stream the input through parse, but it stores its internal representation in a contiguous block (or requires one if doing in-place), and hands out a [pointer, length] via its API (if it's returning a string), which requires contiguous memory.

We don't use virtual memory, so we try to avoid allocations over 128KiB to prevent fragmentation.

We also need to avoid std::thread and related concepts such as std::mutex, and we'd also like to avoid std::shared_ptr.

Good to know. We don't use any of it!

std::future::get/wait?

[jviotti]

For example, RapidJSON can stream the input through parse, but it stores its internal representation in a contiguous block (or requires one if doing in-place), and hands out a [pointer, length] via its API (if it's returning a string), which requires contiguous memory.
We don't use virtual memory, so we try to avoid allocations over 128KiB to prevent fragmentation.

Very interesting. Thanks for sharing. I'll make a note and see what could be done!

std::future::get/wait?

They are only used in various JSON Schema related lower-level components for schema compilation (not for evaluation) and even then, we are actively getting rid of them: sourcemeta/core#651.

---

As an aside, we added jsoncons to our growing JSON Schema benchmark (which we will eventually publish as a paper) and it turns out its quite slow and there are cases where it will even fail to produce the correct results. See https://github.com/sourcemeta-research/jsonschema-benchmark/actions/runs/11237542361. JSON Toolkit is even up to 472x faster than it in some cases!

[andijcr]

we recently introduced jsoncons in our codebase to handle >draft4, to implement json schema support in schema-registry.

I think draft4 is enough for most of internal use cases, but we had an instance where we introduced a draft7 in the code, and it wasn't immediately realized that rapidjson does not support this dialect. the fix in that case was to rewrite the schema in draft4.

personally, i don't like the default open content model of json schema, it makes manually writing schemas bugprone - I lost count of the times I wrote "minumum" instead of "minimum"

[jviotti]

Yeah, I hear you on the open model. Its constraint-based nature can be a bit of a paradigm shift to many. A bit unrelated, but I'm also working on a JSON Schema CLI (https://github.com/sourcemeta/jsonschema) that comes with a linter that is expected to start catching a lot more of those little issues, and might be handy to run on CI. The linter is still a very heavy work in progress, but we are getting there :)