Summary
With this latest release, we’re happy to announce that we have made great strides in improving Windows support for Holochain, particularly for the installation process. By doing so, we hope to demonstrate our commitment to serving the widest possible community of users.
We’ve also introduced improvements and fixes for bridging, improved error messaging, along with a streamlined serialization/deserialization process for the most common type of zome function return value.
Highlights
- Installation: New Windows Install Process Based on Vagrant
- Debugging: Calls to Other Zomes and Bridges Now Log Errors
- Bridging/Breaking Change: Bridge Configuration Checked for Correctness
- Bridging: Live Changes to Bridge Configuration No Longer Require Restart
- Developer Experience: Safe Serialization/Deserialization of Result Type
Details
1. Installation: New Windows Install Process Based on Vagrant
Our goal is to support all major operating systems, beginning with the platforms that developers are most likely to use: macOS, Linux, and Windows. The first two have been well supported from the start, but Windows support has lagged behind.
We realized that moving to a Vagrant-based installer would allow us to support all three platforms with one installation procedure, optimizing our workload and letting us get back to building features.
The astute among you will notice that this solution involves installing Linux in a virtual machine. We hope to have native Windows support once we have enough capacity to devote to addressing cross-platform compatibility issues.
If you’re a Windows user and are unfamiliar with Linux, we encourage you to take it easy, remember to swap \ with / in your folder paths and get acquainted with the Bash terminal. If you run into trouble, come and talk to the friendly developer community on our Mattermost chat server.
2. Debugging: Calls to Other Zomes and Bridges Now Log Errors
In this release, we’ve added error logging for failed calls across bridges and zome boundaries, which should make your life a little bit easier. Previously, errors would merely get returned to the calling function, but now they also get logged on the way through.
This feature is part of our ongoing quest to improve error messages. You’ve heard us talk about this before, and you’re hearing it again. This is because our developer community discovers error messages that lack clarity on a regular basis, and we strive to improve them as soon as we hear about them. They’ll be improved more often as developers use our framework in new ways and suggest ways to make error messages more useful.
Please continue to help us by suggesting or contributing improvements!
3. Bridging/Breaking Change: Bridge Configuration Checked for Correctness
Holochain apps are meant to be architected like a set of microservices unified by a single UI. Sometimes the UI can be the mediator between DNAs, requesting data from one and performing actions in another in response to the data received. But sometimes a DNA needs stronger data integrity guarantees, which can only be provided by talking directly to the other DNA.
For this, we have bridging, which lets one DNA open up a channel to another DNA and call its functions directly. The conductor mediates the communication, providing assurance that the data hasn’t been modified en route.
Bridges set up dependencies between DNAs. You can describe a dependency by the DNA’s hash or by the features it says it has. We call these features ‘traits.’
Previously, the conductor did not alert you to configure bridges that weren’t actually correct. With this release, the conductor analyzes the bridges you’ve configured and tells you if the dependencies aren’t satisfied properly.
Breaking change: Now that bridge configuration is checked for sanity, you’ll need to define bridge dependencies in your zome’s DNA JSON file in order to use bridging. Our next step is to develop tooling to automatically generate this JSON from your zome source code.
4. Bridging: Live Changes to Bridge Configuration No Longer Require Restart
The conductor admin API lets you modify a running conductor’s configuration, including bridge configuration, on the fly. This, in turn, lets you incorporate features into your app’s GUI to allow users to spin up new apps and choose which DNA microservices to use for particular features (e.g., swappable commenting, annotation, or user profile auto-fill).
Previously, when you used the admin API to configure bridges, the changes wouldn’t take effect until the conductor was restarted. Now, they take effect immediately.
5. Developer Experience: Safe Serialization/Deserialization of Result Type
App devs have been giving bridging a try. Bridging allows you to call another DNA’s zome functions, and zome functions return a special type of Result. (For those of you who aren’t familiar with Rust’s Result type, it allows you to return either a value or an error from your function.) However, when the calling function receives the result, it’s just a JSON string. App devs have found it annoying and error-prone to convert this back to a Result type.
Here’s an example of such a bridge call, which wasn’t guaranteed to work:
let result_json = hdk::call(/* params for fn in other DNA omitted */)?;serde_json::from_str(&String::from(&result_json))
.map_err(|e| HolochainError::SerializationError(e.to_string()))?;
To improve the situation, we’ve implemented a conversion from JsonString to Result.. Here’s how that bridge call would look when using this feature:
let result_json = hdk::call(/* params for fn in other DNA omitted */)?;result_json.try_into()?;
We hope this new feature saves you keystrokes and headaches.
Development Status:
- 0.0.19-alpha1 Released
- Next: 0.0.20-alpha1
