Polkadot Brussels Technical Summit 24’ - Developer Experience of the Polkadot-SDK
Host: @pierreaubert | @bkchr | @OliverTY
Slides
We started off with the Question “Why this workshop?”
- Developer Experience can be improved
- Better DevEX leads to an overall better UX
- Polkadot is nothing without it’s builders
- A better DevEX makes it easier to build good quality products
Overall the main goal for this workshop was to showcase some past efforts, communicate ongoing and future efforts and gather feedback from builders. Alongside this, an open question was asked
What do you expect & hope for?
There were identified problems right from the get-go
- Node Maintenance Burden
- Unstable environment for builders
- Unclear visioning scheme
- Uncertainty about breaking changes
We then split the initiatives into Past, Present & Future initiatives
Past & Completed
Genesis Builder API Was the first to be discussed. An API that’s primarily used to facilitate the creation and management of the genesis storage. Devs can define and configure various parameters and accounts that are essential for a chain’s initial setup. To summarise, you can now generate spec from a runtime, enables universal omni-tooling and there’s no longer any need to ship specs.
The Omni Bencher is next on the list of completed initiatives. A tool designed for benchmarking any Polkadot Runtime, providing a way to measure the performance of various runtime components without the need for them to be integrated into the node.
The tl;dr is
- Benchmark any Polkadot Runtime
- Remove code from the nodes
- Requires Genesis Builder API
The Umbrella Crate were also a topic of discussion. Umbrella crates re-exports all published crates of the Polkadot-SDK. This can dramatically help developers select a valid set of versions for all underlying dependencies. You can now use this Umbrella crate and remove lots of dependencies from your runtime and node crates.
- 1 crate to version them all
- Useful for runtime and node building
- Reduced maintenance effort
“Does the Umbrella crate have any disadvantages?“ - Some attendees had concerns regarding build time & how this new crate would affect that.
To clarify, yes. We are technically trading in build-time with convenience here. Using the Umbrella Crate is easier than selecting every crate version manually, but it can increase the build-time.
There is however a sweet spot where you can have nearly both by disabling the default features. Every bundled dependency is also exposed as a feature name, to allow selecting to only build the ones that you need.
As the discussion progressed, a key point about the size of the SDK was raised.
As we progress, the SDK continues to grow & it’s getting to a point where it could become a disaster. Waiting 5 minutes + for it to compile is never okay. If the SDK gets any larger, we’ll have to break it apart
After this, another open question was raised, “Should we work with IntelliJ?” If you’re unaware of what IntelliJ is and does, then check out this article here: https://www.jetbrains.com/idea/. This was proposed as a potential alternative to the VS Code Plugin.
Present & In progress
The Omni-Node discussion was raised. To learn more about this, we recommend that you check out the Forum post by Kian
Omni-Node features;
- Run for any Polkadot Parachain
- Builders can focus on business logic
- Compatible with custom RPC’s [EVM]
- Open Spec Discussion
- Planned for EOY
For the most part, the cost was the most important part in this discussion.
Release Comms was next on the agenda, a topic that many in the Polkadot Eco have been eager to discuss.
What’s in progress?
- CHANGELOG for the SDK & Runtime
- Note: CHANGELOG has already been implemented!
- Release calendar
- Mail/TG/Matrix notifications
An open question was asked which sparked a discussion
“Is this good enough?”
Attendees pushed for more persistent reminders prior to the release, essentially pushing for a wave of constant reminders leading up to it.
Another open question to the teams and community was “What affects protocol Dev’s the most?” For example, ‘What do Parachain Devs need in terms of XCM?’ If we can find and improve this mode of communication, that would be ideal.
Most Core Devs / Protocol Devs usually write the spec for the feature themselves, although they do require feedback from the devs working within the project teams. Whilst this would be ideal, that call for feedback is sometimes left ‘unheard’.
This leads to the feature being released with little to 0 feedback, thus causing the feature to be not used or broken for specific teams.
To quote “If there was no breaking change, would anyone care?” Parachain Dev’s need more structure in terms of feedback. Ideally, written feedback would be ideal to the Core Parity Devs.
Throughout the discussion we also touched upon Stable [LTS] Releases
- Breaking changes every 3 months?
- Patches every 2 weeks?
- Naming scheme e.g. stableYYMMDD
- Already implemented, changed to stableYYMM with last release being called stablE240
- Planned instead of the 1.15 release
- Note: Release 1.15 is already live
A question that we’d like to ask the community & the teams working within Polkadot,
What is a good LTS for you?
Whilst some had proposed 3 month changes and others 6 month changes, how much of a difference would this make to your development & could the chains keep up the breaking changes at these time intervals?
Guides we’re also discussed, expressing the urgent need for them to be released with each breaking change. It’s been done with Async backing, POV Reclaim etc etc, so this is something that we as an ecosystem should pursue.
The conclusions we’re;
- If there’s a breaking change, a guide released alongside it would be very helpful
- A vote should be held on the frequency of the breaking changes among parachain teams
Coming towards the end of the workshop, we touched upon some future initiatives that are yet to come, so we’ve included a short summary of each below.
E2E Testing was first in the section
- Prevent releases from breaking things
- Mini Polkadot Fork for testing [Doppelganger]
- Cover Major XCM use cases
- Builders can add tests
And last but not least, we’ve got Monitoring
- Central data lake
- Custom monitor and ingester scripts
- Fan out information to subscribers
- Don’t silo information inside Parity
This brought us to the end of the workshop, although not the end of the discussion. Another topic that was brought up was the Polkadot Forum, the ecosystems go-to discussion platform.
People believe that the Forum were constructed to make noise, whilst it’s been busy and active, how much of that noise is constructive?
- We should use the category view instead of the default view.
- A comparison between how the Cosmos Forum looks vs Polkadot’s Forum looks was mentioned
- Do we prefer how their’s looks over ours?
- A comparison between how the Cosmos Forum looks vs Polkadot’s Forum looks was mentioned
- We should also utilise the tags a lot more throughout the forums
- What tags & categories should we start to use?
The last & final open discussion was surrounding the Technical Summit itself. It was clear from the responses and engagement of the attendees that more initiatives like the Summit are needed.
- Could we do both in-person Summits and online group discussions to follow up to discussed issues?
- How effective would an online summit / follow-up be?
Action Points & Key takeaways
Overall the Developer Experience of the Polkadot-SDK Workshop was a great success, we’d like to extend a huge thank you to our experts @bkchr @pierreaubert & @OliverTY for their amazing work with putting the presentation together and hosting a very productive workshop.
We’d also like to say thank you too all those who are actively engaging and contributing towards these discussions.
We’ve included some action items below to consider, these points are only a guide & we encourage you, the community, to help us build upon what was discussed and come with some actionable recommendations for the teams.
- Forum Revamp should be taken into consideration
- How can we host more initiatives like the Summit & can we do them online?
- If there’s a breaking change, a guide should 100% be released alongside it
- Teams should vote and voice their opinion on how often they’d be able to manage breaking changes [3months vs 6months]
- Call 2 Action on Open Q’s throughout the Doc
Please stay turned throughout the week & check out the polkadot-summit tag as more discussions and workshops will be released shortly.