Question
Reach frontend and deployed contract info: fixed binding or dynamic resolution for rollback after a failed redeploy
Ari Maple
0 reputation · 08 Jul 2021, 07:05 UTC
28K views
Loading…
0 reputation · 08 Jul 2021, 07:05 UTC
We deploy a Reach DApp to an Ethereum-compatible connector, where contracts are immutable, so any upgrade means compiling a new artifact and redeploying rather than patching in place. Our frontend currently hardcodes the published contract info (address) from the most recent deployment.
After a redeploy produces a broken or unexpected artifact, we want the frontend to roll back by repointing to the prior deployment without shipping new code. That raises an integration-boundary decision: should the frontend bind to a fixed contract info value baked in at build time, or resolve contract info dynamically from configuration or a registry at runtime? A fixed binding makes rollback a redeploy of the frontend; dynamic resolution makes it a config change, but adds a trust and consistency question about who can update the pointer.
There is also a versioning constraint: artifacts compiled under different Reach stdlib versions may not interoperate, so any rollback target must have been built with a compatible stdlib.
Which binding strategy do Reach-based frontends typically use so that rollback after a failed redeploy is a configuration change rather than a code change? How should stdlib version compatibility between the old and new artifacts be checked before repointing? On connectors that permit in-place application updates (e.g., Algorand), does the same decision still apply?
35275 reputation · 08 Jul 2021, 18:26 UTC
To enable rollbacks as a configuration change rather than a code change, Reach-based frontends should use dynamic resolution. Instead of hardcoding the contract address (fixed binding) into the build artifact, the frontend should fetch the current active contract information from an external source at runtime.
The most common pattern is to host a lightweight configuration file (e.g., config.json) on a CDN or a secure API endpoint. The frontend requests this file during the initialization phase to determine which contract address to bind to the Reach loadContract or equivalent provider calls.
Because Reach artifacts compiled with different standard library (stdlib) versions may be binary-incompatible, the configuration registry must store more than just the address. It should include the compiler version or stdlib hash used for that specific deployment.
The frontend should perform a compatibility check before initializing the contract:
reach{ "address": "0x...", "stdlibVersion": "0.1.x" } from the registry.stdlibVersion against the version of the Reach SDK bundled with the current frontend build.On connectors like Algorand that may allow certain types of application updates, the decision to use dynamic resolution remains the same. While the address might stay constant in some update scenarios, the logic of the contract changes. Dynamic resolution allows you to track the specific version of the logic currently deployed, ensuring the frontend remains synchronized with the contract's expected interface.
To verify this setup, perform the following scoped tests:
config.json to point to a previous deployment address and verify the frontend redirects transactions to the old address without a rebuild.stdlibVersion in the config to a known incompatible version and verify the frontend blocks the connection instead of crashing during a transaction.Diagnostic Detail Needed: Are you using a centralized backend for your configuration, or are you considering a decentralized registry (e.g., an on-chain directory contract)? The latter would introduce additional gas costs and latency to the frontend boot sequence.
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.