Thanks for the input; it’s helpful!
You mention Typescript, which I recognize is powerful tech and many devs use it for explicit type management, and it could have benefits in this context, however I think not using it doesn’t stop a schema being shared-and-leveraged in the front-end.
For instance, in generating a form dynamically for a post type (e.g. “event” or “group”), in theory you can easily render fields and validators given a JSON object (being the schema). This doesn’t need Typescript at all. I mean, that is what I’m starting to do now in my front-end with custom models in the global store (VueX). The problem is there’s no relevance (synchronization) to the back-end. When I make changes in the back-end, I have to come and manually modify the models in the front-end… which is an opportunity for mistakes (e.g. typos).
I think if there were some schema export from Strapi, that it would take in the front vs back aspect. That some parts of the schema wouldn’t be exported because it doesn’t need to be, or for security reasons can’t be exposed externally.
It would be awesome if Strapi had a “front-end schema”, such that this is something intended for the front-end to use PROGRAMMATICALLY, in order to properly communicate with the back-end. In hindsight, this is what I desire, and I was crossing my fingers Strapi has this but I’m just overlooking it (due to semantics?).