3f597aae16
* Tighten result type Command execution can't result in a sequencer error * New helper method for extracting used contracts * New error clause * Add a DAO query for the maximum time of contracts * Implement algorithm for finding ledger time CHANGELOG_BEGIN CHANGELOG_END * fixup ledgerTimeHelper * Use new ledger time algorithm * Mark LET/MRT as deprecated CHANGELOG_BEGIN - [Ledger API] DAML ledgers have switched to a new ledger time model. The ledger_effective_time and maximum_record_time fields of command submission are deprecated, the ledger time of transactions is instead set automatically by the ledger API server. Ledger time is no longer strictly monotonically increasing, but only follows causal monotonicity: ledger time of transactions is greater than or equal to the ledger time of any used contract. See `#4345 <https://github.com/digital-asset/daml/issues/4345>`__. CHANGELOG_END * Add ledger time skew check * Remove command updater LET/MRT are now deprecated, this class is now useless * Remove old time model validator * Switch to new time model check: kvutils * Switch to new time model check: in-memory ledger * Switch to new time model check: SqlLedger * Use initial ledger config * Ignore user provided LET * Use TimeProvider in submission services * Use deduplication_time in daml-script runner - Also remove unnecessary command completion output of CommandTracker. - Remove usage of maximum record time in CommandTracker. * Use arbitrary default value for deduplication time * Use built-in Instant ordering * Remove obsolete test * Remove obsolete test: CommandStaticTimeIT * Refactor test: TransactionMRTCompliance * Disable test: CommandTrackerFlow timeout * thread maxDeduplicationTime through to CommandTracker * Improve test * Refactor command client configuration * Deduplication time should always use UTC * Add missing method in TimedIndexService after rebase * Put more details into the deduplication error response. * Use system time for command dedup submittedAt. * Use explicit UTC time source in command validator * Revert CommandTracker[Flow] to previous completion-recovering-behavior * Adapt scala client command config to new config params Co-authored-by: Gerolf Seitz <gerolf.seitz@digitalasset.com> |
||
|---|---|---|
| .. | ||
| backend | ||
| docs | ||
| frontend | ||
| integration-test | ||
| .gitignore | ||
| BUILD.bazel | ||
| Makefile | ||
| README.md | ||
Navigator
The Navigator is a web-app that connects to any Digital Asset ledger and allows the user to inspect contracts, create contracts, and exercise choices.
The Navigator can be used in development mode (see below) or packaged into a "fat" JAR that includes the compiled frontend assets for distribution.
Navigator architecture
To learn more about developing the different parts of the Navigator see:
Building Navigator
To build a "fat" JAR of the Navigator that includes the pre-compiled front-end assets, run:
bazel build //navigator/backend:navigator-binary_deploy.jar
This produces a "fat" JAR bazel-bin/navigator/backend/navigator-binary_deploy.jar which can be run with:
java -jar bazel-bin/navigator/backend/navigator-binary_deploy.jar
Notable things in the Navigator build:
backend/src/test/resources/schema.graphql
Manually written, must be consistent with backend/src/main/scala/com/digitalasset/navigator/graphql/GraphQLSchema.scala. Consistency is checked in a test.
frontend/src/**/api/Queries.ts
Generated from backend/src/test/resources/schema.graphql with an external codegen tool.
Currently, these files are checked in and updated with make update-graphql-types.
frontend bundled code
Code from frontend/src/**/*.ts*, compiled using TypeScript, and bundled with Webpack.
Output includes:
bundle-[hash].js: bundled frontend code, name uses content hasing.browsercheck-[hash].js: tiny module for checking browser compatibility, name uses content hasing.- Several image and font files, referenced by the above modules. File names use content hashing.
index.html: Single page application main entry, references the above modules.
Note: Browsers are instructed never to cache index.html, and indefinitely cache all other files. This is why content hashing is used.
backend binary
Scala binary, compiled as a fat JAR.
Code from backend/src/**/*.scala, bundled frontend code is copied to backend/src/main/resources/frontend.
backend version
The version is included as resource files in the Navigator fat jar. This is to reduce rebuild times when the version changes.
frontend development build
For developing frontend code, webpack-dev-server is used. This serves the current frontend code on a separate port, and does:
- Watch
*.tsfiles for changes - Perform incremental builds
- Send a push notification to the browser, automatically reloading the page when the build is finished.
- Forward network requests to a different port, where a Navigator backend is expected to run.
This is orders of magnitude faster than what the current Bazel build offers, so it is desirable to keep the webpack-dev-server setup working.
Note, the browser is instructed to cache assets based on the SDK version. During development this is too aggressive and you will need to manually refresh to see updates to the front-end.