Kubernetes Objects/Model types backed by generic resource with accessors for (de)serialization and API/UX

[manusa]

Originally suggested by @metacosm in quarkusio/quarkus#42028 (comment)

To improve the behavior of the Fabric8 Kubernetes Client when compiled to a native image using GraalVM, the model types can be implemented in a more generic way so that they are all backed by a common data structure (Map, JsonNode, etc.) that can be easily serialized/deserialized without requiring reflection.

Closely related to quarkusio/quarkus#42110

---

Additional context:

Wild idea (because this would change a lot of how the client work currently): could we keep the current model API but have the objects backed by a generic resource. Instead of all model objects being generated individually with appropriate fields, we would just getting the accessors, which would take care of accessing the appropriate key-value in the underlying map?

Maybe we can discuss this during a call. This might get complicated especially when trying to deal with deserialization of non-standard fields, etc. Also hard for the sundrio builder-generation integration.

I would love to also discuss this in a call, since it could even be related to the work that I'm doing for the PoC that I mentioned in one of my former comments.

Originally posted by @mariofusco in quarkusio/quarkus#42028 (comment)

/cc @metacosm @galderz @geoand @jorsol @mariofusco

[manusa]

There's already an active initiative to replace the current way we are generating the model types by something faster and easier to maintain: #6130

Once this is in, implementing something compliant with what @metacosm suggested should not be difficult.

I already have an idea in mind.
If I have time to work on it I will probably have a PoC by the end of the day to illustrate this idea.

[manusa]

This is a more or less working PoC of the "wild idea" proposed by @metacosm

https://github.com/marcnuri-demo/fabric8-generic-kubernetes-resource

Check the readme for more details.

n.b. This has been done manually to see if it is interesting or not. In case we move forward, the generator would be tuned to automatically generate the types according to the proposed structure (or its future iterations).

[manusa]

I need to check if this (PoC or the Fabric8 Deserializer) can be evolved to do something like what Mario proposes in:

• Generate faster reflection-free Jackson serializers quarkusio/quarkus#41063
• Document reflection free Jackson serializers quarkusio/quarkus#42289