aster.Web Data / Docs Aster UI ↗

Aster Web Data / How it works

In the browser

Build and test screens against Aster UI's mock, which runs the Aster Web Data engine in the browser, before the backend exists.

A screen team usually waits for the backend: the database, the service and its endpoints. With Aster UI's mock they can start on the screens first. The mock runs the Aster Web Data query engine in the browser, compiled to WebAssembly, and answers OData requests from sample rows the page gives it. A screen built against it sends the same requests it will send to the real service, so moving to the service is a change of URL.

Build the screens first

The mock is Aster UI's development package @getaster/mock, which contains the module odata_mock.wasm:

npm install --save-dev @getaster/mock

The page starts the mock with a metadata document and sample rows. The mock serves that metadata and the service document, and answers reads, writes and $batch over the rows. Aster UI's grids and forms take their columns and fields from the metadata, as they do against a live service.

A team can then work in this order:

  1. Write the model and the first screens against the mock, with sample data in the page.
  2. Try the filters, sorts, pages and forms in the browser, with no server running.
  3. When the model is settled, set up the database and the service, and run check against it.
  4. Point the screen at the service's OData URL. Its requests stay the same.

Aster UI describes the screen side, and With Aster UI explains how the service and the UI connect.

How the mock differs from the service

The mock contains the OData parser, the planner and the in-memory engine, the same engine the server uses for the parts of a request no database runs. It has no database, so every result follows Aster's written rules rather than a database's. Text comparison, case mapping and the digits of decimal and double arithmetic can therefore differ from a production database, for example one with a case-insensitive collation. Comparison and arithmetic rules lists those rules.

The rows live in the page's memory, and every filter and sort runs over the whole set, so the mock raises the engine's row limit to 2,000,000 rows. A request past it fails with QueryTooExpensive, as on the server.