Under the hood
In a conventional application, a screen is a file of code. In CloudWinks, a screen is a row in a table describing what it contains and how it behaves. The client reads that description and draws it. Everything else in the framework follows from that one decision.
The request path
A Flutter client — in a browser or on a phone — asks the framework for the state of the application the user signed into.
A single generic endpoint calls a named database function and returns the state: which screen is showing, what fields it has, what its menu holds.
The definitions live in the application's own schema, alongside its business data. One database server, separate schemas, one backup story.
The framework's widget registry maps each field type to a control and draws the screen. Nothing about that screen needed its own code.
Definitions
An application is a folder of numbered definition sets plus one setup file that declares its identity. That is the unit of work.
| Definition folder | What it holds |
|---|---|
1_0_prerequisites | Anything that must exist before the schema is built. |
2_tables | The tables and columns, as JSON, that become the schema. |
3_0_pre-seeding | Data that must be present before the main seed. |
5_0_special_functions | Database functions specific to this application. |
5_1_view_functions | Functions that read and shape data for screens. |
6_0_views · 6_1_function_views | Views and the functions behind them. |
7_0_seeding_patterns · 7_1_seeding | Patterns and the seed data itself. |
8_special_menus | The navigation hierarchy this application presents. |
10_codercody_seeding | Implementation notes carried into the build. |
Those conventions are not style preferences. They are what lets one pipeline build every application with the same commands.
The stack
One codebase builds both the browser application and the phone application. The shell, the navigation state, the widget registry and the field renderers all live here, shared by every application it carries.
A shared .NET service API sits between the client and the database. Almost everything goes through one generic query endpoint that calls a named function, which is why applications do not each need their own backend.
Build, import and seed run from one orchestrator. It reads the definitions, creates the schema, registers the screens and loads the data, with a report of every step.
The single store for definitions and business data, one schema per application, with a shared identity base underneath.
Authentication and file storage, so sign-in and uploads work the same in every application. Google sign-in is the provider in daily use today.
Hostnames, TLS and a request gate in front of the API. Which application a host opens is worked out from the definitions, not from a separate configuration file.
Why it matters
A business buys four products for four departments. Each has its own login, its own idea of what a customer is, its own reports. Integration becomes a project in itself, and every fix has to be made four times because it was written four times.
Then a fifth need appears, and the answer is a fifth product.
Identity, permissions, files, messaging, reporting and workflow are written once and shared. A new application contributes its own tables and screens, and inherits everything else.
Improve a shared component and every application that uses it improves. Add a field and the database, the screens and the data all know about it, because the field is a definition rather than a fragment of code in three places.
We will walk you through the framework and the applications in a development environment, and be straight with you about what is finished and what is not.