Summary
With this release, we’re setting the stage to move away from static UI servers for conductors and enable offline source agent validation. We have also introduced a new tool for debugging and made the get_links function more efficient. Importantly, we’ve included a brief note on handling version conflicts, which will be expanded upon in a separate article.
Highlights
- State Dump Flag for Debugging
- New UI Web Server Based on Nickel
- Deprecation Warning When Starting a Conductor With a UI Server Configured
- get_links Optimized for Fewer Network Calls
- Dealing with Version Conflicts (preview)
Details
1. State Dump Flag for Debugging (#1601)
We have made Holochain Core debugging a lot easier by adding a new config flag — when activated, it will print a human-readable dump of the redux state every 10 seconds. The log statements will give you a quick overview of the important parts of the state machine. The frequency of the dumps means that, if something goes wrong, you can scroll back up and see what led to the incident.
While this new config flag is mainly driven by internal core team needs (i.e., core debugging when working with networking), it’s also a step toward helping DNA developers get a better sense of what’s going on with their apps. Imagine, for example, you have a running app on the network, or you have a number of nodes, and something is not working — a state dump can help you see if a particular node is actually holding an entry.
Going forward, we will use this flag when lib3h is ready to be tested, and subsequently integrate it with Core — because n3h and Core are two separate processes, we had to add a similar state dump to n3h separately. If you look at app-spec logging output, you will see both in great detail. With lib3h, we can basically pull everything together into one state dump. We also plan to build a nice UI for the dump data so you can see all the nodes of an app, even in a network state.
2. New UI Web Server Based on Nickel (#1595)
If you have been using the static file server, you may have experienced issues with certain things rendering and the content-type headers causing problems for different browsers. We have resolved this issue by switching our static server to use Nickel. We previously had a build file that would force recompilation of all its dependencies, and therefore broke incremental compilation.
We’ve refactored the static server so that we can add other implementations if the need arises. There’s also an extra configuration in the conductor config so that the server can be bound to a different address and default rerouting behavior can be set.
3. Deprecation Warning When Starting a Conductor With a UI Server Configured (#1602)
Although we’ve fixed the static UI server, you should know that static UI servers for conductors will be removed in a future release. Because UIs need to know which conductor interface to connect to, introducing a web server to the Conductor for hosting UIs made sense. Our UI server adds a virtual JSON file that provides this information, which is then used by hc-web-client on the other side to initialize the zome interface connection. As an interim solution, used mostly by developers, it is viable and makes sense.
However, in targeted production use-cases, hApps hosted through Holo and run completely in the browser. With hApps running locally in an end-user Holochain conductor deployment, a special http server for UIs doesn’t really make sense. With Holo hosting, the hosts should provide static file serving via a proper, production ready server. Also, once we have implemented the Holo light-client, both the UI and the Conductor (compiled to WebAssembly) will run in the browser.
With a full Holochain installation on the other side, we are working toward an integrated client installation that wraps the conductor inside an Electron app and renders UIs directly from files. In this case, the websocket connection to the conductor API, which is used to call zome functions via hc-web-client could even be replaced through a Unix domain socket (or similar means of IPC).
In either case, we would not want to use a UI server that is integrated into the Conductor — it just adds unnecessary complexity.
The static UI server will not be removed until the long-term solution is implemented. In the meantime, developers will receive a warning in their consoles when conductor configs have entries in the ui_servers or ui_interfaces fields.
4. get_links Optimized for Fewer Network Calls (#1607)
The get_links function used to require at least two network calls. The first was getting the list of links from the DHT node responsible for the base entry, where each link is represented as the address of the corresponding link_add entry. The second request per link was to retrieve the link_add entry, and thus, the target of the link.
This could potentially be very expensive if a DNA stores a lot of links branching off of the same entry.
Therefore, we wanted to limit the number of network calls, making one call would give you everything you need.
We’re now caching those link_add entries on the DHT node that is holding the base. When a link query is received, it will look up the list of all the links, get the link_add entries from the local cache, and send back the complete results as needed by hdk::get_links. This will be a big performance win for apps and the network.
5. Dealing with Version Conflicts (preview)
We’ve heard from several DNA developers who have experienced failing builds when updating to new Holochain versions. This is typically due to mismatches in the versions of the different components used in building DNAs — the Rust compiler, HDK, hc binaries, the Conductor, or the Rust compiler for the Conductor. We will have a longer discussion of how all these moving parts work together in a separate article, and we strongly recommend that you use Holonix to manage these components rather than directly downloading the binaries. It will make development much easier, and will ensure that version conflicts are much less likely to happen.
Development Status:
- Released: 0.0.26-alpha1
- Next: 0.0.27-alpha1
For all changes related to this release, please see the changelog.
