daml/navigator
Andreas Herrmann df7bff6288 Update to bazel-0.27 (#1957)
* Bazel: 0.24.0 -> 0.27.0

* Update rules_haskell for Bazel 0.27 compatibility

* Update bazel-deps and bazel-watcher

* Windows escape JVM flags

* load commands at top of .bzl file

Bazel 0.27 no longer allows load commands that are not at the beginning
of the file.

* Update Bazel rules

* subpackage boundary

* native is not defined in BUILD files

* yarn: @bazel/hide-bazel-files

Seems to be required since latest rules_nodejs version. Otherwise, yarn
fails with errors about existing BUILD or BUILD.bazel files.

* grpc-java plugin visibility

* Update fat_cc_library

* Nix Python3 toolchain

* Iteration over depset

* dev_env_package: Create symlinks one level deeper

To prevent symlinking the BUILD file as well. The nested BUILD file
confuses Bazel as of 0.27 and rules_nodejs cannot find the node
executable anymore.

* Update rules_nodejs

* Add managed_directories for node_modules

* hie-bios: Extract bazel-genfiles from bazel info

Bazel 0.27 changed the genfiles location which breaks the hie-core test
on macOS.

* update cc_wrapper to Bazel 0.27

* bazel info -> bazel info bazel-genfiles

* Fix typo in BUILD

Co-Authored-By: Stefano Baghino <43749967+stefanobaghino-da@users.noreply.github.com>
2019-07-05 14:04:47 +00:00
..
backend daml-lf: create value version 5 for enum types (#1917) 2019-07-03 07:16:52 +00:00
docs Update urllib version to avoid security vulns warning (#864) 2019-05-02 15:39:32 -04:00
frontend Update to bazel-0.27 (#1957) 2019-07-05 14:04:47 +00:00
integration-test Remove damli completely (#481) 2019-04-15 14:47:59 +02:00
.gitignore open-sourcing daml 2019-04-04 09:33:38 +01:00
BUILD.bazel Enforce consistent formatting of BUILD files. (#412) 2019-04-12 13:10:16 +02:00
Makefile Navigator: Remove unused Makefile targets 2019-04-05 12:10:55 +02:00
README.md Fix DAML runtime for the new DAML-LF type Map (#204) 2019-04-10 21:30:33 +02:00

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 *.ts files 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.