8158269b7d
* Remove ExercisedEvent in Event oneof. The Event message is only used in the Transaction message. Flat transactions do not contain exercised events, but only created and archived events. Therefore we can remove the ExercisedEvent from the Event oneof, without breaking transport compatibility. HOWEVER: The Java Bindings used to use the data.Event class for both flat transactions and transaction trees. To properly represent the actual event types in the two transaction structures, 1) Event is now and interface and is only used in the Transaction class. 2) there is a new interface TreeEvent, which is used in the TransactionTree class. * CreatedEvent implements Event and TreeEvent * ExercisedEvent implements TreeEvent * ArchivedEvent implements Event Some "pathological" cases where an occurrence of an exercised event would have resulted only in an exception, are now removed (see change in LedgerApiV1.scala). Fixes #960. |
||
|---|---|---|
| .. | ||
| 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 commit and version
The commit and version are included as resource files in the Navigator fat jar. This is to reduce rebuild times when the git commit 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.