Hi @Ethan_Veres, and thanks for the great question.
In our framework the Cube and View are tightly coupled and need to be constructed together specifically for the queries they’ll serve. We built this framework to support a developer building all three (Query, Cube, and View) at once on their laptop along with the web application features that rely on them.
We wanted to make development iteration for this part of the process as quick and convenient as possible, since it can’t be automated, and then automate everything else around deploying it to eliminate tedious repetition and minimize errors.
The View is the dynamic part that changes when deploying into snowflake, and this is how we can deploy common, reusable cubes into data warehouses with different tables. The details of how we do that are very specific to our implementation but the general idea is writing the Views as templates (a SELECT statement with variables for the table and column names in the FROM clauses) and then rendering the template with parameters specific to each data warehouse it is being deployed into.
As for schema versioning, Cube.js supports this via authentication token payload properties. You can include the information you need to select a schema (name, version, whatever) in the token when sending requests to Cube.js server. Then in your Cube.js server config you can read the schema info properties from the auth token and use them to set the app ID (contextToAppId) and fetch cubes (repositoryFactory) for the schema version from your API or from files bundled with the Cube.js server.
I hope this helps. Happy hacking!