When it comes to Substrate developer experience specifically, @kianenigma originally wrote up this proposal and I’ve commented with my 2c on how starting a node and tinkering with Substrate should look.
opened 08:42AM - 31 May 23 UTC
T1-FRAME
related to paritytech/polkadot-sdk#186 paritytech/substrate#14137
## Vision … 1
As it stands now, we take it for granted that that one builds a runtime, then pulls the substrate-node-template (or some similar repository of code), integrate it in a "blind" fashion (using probably nasty trial and error, without really knowing what they are doing) and never look at the node side code ever again.
Taking the same mindset that I talked about for a "substrate-node-builder-cli" [here](https://github.com/paritytech/polkadot-sdk/issues/186), Imagine an alternative like this:
* You build your pallet and runtime using paritytech/substrate#14137
* Then, you build a new project like:
```
[dependencies]
my-runtime = "1.0.0"
substrate-node-builder = "1.0.0"
```
* a `main.rs` that looks like:
```rust
use substrate_node_builder::{Builder, Consensus, Subcommand};
let node = Builder::default()
// wire your node and runtime. All of the random types that the node needs from the runtime should not
// be raw re-exports anymore, and should be done via a `trait`.
// this should also be helpful
.runtime(my_runtime::MyRuntime)
// define your consensus engine. Can only be one of a few options.
.consensus(Consensus::ManualSeal)
// Tweak the list of sub-commands from `Default`
.add_subcommand(Subcommand::TryRuntime)
.add_subcommand(Subcommand::Revert)
.remove_subcommand(Subcommand::Benchmarks)
// Tweak the list of RPCs endpoints
.add_rpc(Rpc::Foo)
.remove_rpc(Rpc::Bar)
.build()
.unwrap();
fn main() {
node.run();
}
```
This is basically what a "creat-substrate-app" CLI would do for you, but done via code. Once we have this, the CLI would be rather trivial to build, and would merely be something that converts a YAML/JSON file t the above piece of code.
## Vision 2
I have little clue about what are the blockers to reach the above. Historically I knew that code in `service.rs` has been quite a difficult one to play with. But, looking at a very simple node-template with manual seal, I _think_ I can wrap my head around it and conclude that the above is feasible.
But, if the above is not possible, what I would be a good improvement to the existing quo, especially from a DevEx perspective is to replace the need to clone any _code_ for the node software with pure _binaries_.
That is, once paritytech/polkadot-sdk#62 is done, and there is less (hopefully none!) strict dependency between the node and the runtime, the process to learn FRAME and run a basic chain would be:
1. build your runtime, again with paritytech/substrate#14137
2. go to a release/download page where you are presented a list of node software different pre-configurations, such as consensus options.
3. You download the software, for example `node` and run `./node --runtime path/to/wasm.wasm <rest of substrate cli opts>` and the rest should work.
I am not sure if this is actually much simpler than the above, as it would require some checks like seeing which runtime api/rpcs are available to become runtime (os opposed to the current compile-time) checks.
More broadly, it’s clear that tools and SDKs don’t need to just work well, but feel good to use. In retrospect this is one of the largest pieces of developer adoption. For this we need to be very thoughtful about APIs.
6 Likes