Switch schema validation library from superstruct to zod

[tadayosi]

hawtio-react uses superstruct for typescript schema validation, but popular AI libraries such as LLamaIndex.TS and LangChain.js all use zod, which is more popular than superstruct. It should be convenient for hawtio-react to switch to zod in advance, in order to utilise those AI libraries to support some AI features in the future.

[grgrzybek]

Interesting... Are there any real-life benchmarks for that?
I see https://zod.dev/v4#benchmarks, but it compares zod v3 with v4 only.

When I first saw superstruct usage in Hawtio, it was when I was checking (really) large JSONs from AMQ - tens of thousands of the same JSON objects representing AMQ Queue MBeans (with almost hundred MBean attributes and operations).
At this time I was wondering about performance impact, but didn't dig too deep, because real performance decrease was related to duplication, not to type validation.

But still - type validation is performed on JSONs coming from Jolokia endpoint. We initialize such connection when Hawtio starts or when we connect to external Jolokia agent.

Maybe we could make entire JSON validation optional (I'm not saying we should remove it entirely) and do some validation at initialization/connection time?

[tadayosi]

@grgrzybek you might find this interesting, but the conclusion seems to be rather discouraging 😞
https://dev.to/nicklucas/typescript-runtime-validators-and-dx-a-type-checking-performance-analysis-of-zodsuperstructyuptypebox-5416

[grgrzybek]

Another reason to define stages:

• initial connection to Jolokia endpoint (own or remote) with validation
• using JSONs from Jolokia without type checking

And zod seems to be slower than superstruct? Another example of "slower, but newer = more cool" framework?

[tadayosi]

@grgrzybek The main reason for the proposal is that zod is far more popular than superstruct and both LlamaIndex TS and LangChain.js depend on it. If we continue to use superstruct while introducing any of the AI libraries, we'll end up duplicating the two where we only need one.

But probably you're right, we should consider it seriously only when we really want to integrate any of the AI libraries.

[grgrzybek]

Generally - when dealing with any/unknown data, I fully agree - let's switch to more popular and better supported/maintained libraries.

Simply with Jolokia, when after establishing the connection we rather trust the incoming data, I'd switch to optional type validation.

[tadayosi]

Simply with Jolokia, when after establishing the connection we rather trust the incoming data, I'd switch to optional type validation.

Generally I agree with your opinion. However, I'm still not sure if it's still the case with hawtio, as most of the reason why we need to use schema validation is because the returned JSON data from Jolokia itself is so flexible that hawtio cannot tell the correct data type for each response; a response can be the list of full mbeans with FQDN (with or without optimisation), mbeans from a single domain, or even a single mbean info.

We trust that the incoming data is fully compliant with the Jolokia protocol contract, but the contract itself has a flexibility that without schema validation we cannot tell the right working data type...

https://github.com/hawtio/hawtio-next/blob/28016194918cea17fd5da50ca4a3c9b493d92271/packages/hawtio/src/plugins/shared/jolokia-service.ts#L661-L697

[grgrzybek]

because the returned JSON data from Jolokia itself is so flexible that hawtio cannot tell the correct data type for each response

I forgot that maxDepth may impact the schema...

I was thinking rather only about the initial list operation which is invoked with maxDepth=9 to get everything - so we know there's a list of domains/mbeans/ops+attrs+desc.