search

cosmos / cosmos-sdk

:chains: A Framework for Building High Value Public Blockchains :sparkles:
https://cosmos.network/
Apache License 2.0
6.17k stars 3.57k forks source link

EPIC: Dev UX #13085

Closed tac0turtle closed 1 week ago

tac0turtle commented 2 years ago

Summary

Much of the cosmos-sdk was written many years ago while it was evolving and growing its user base. In these times its hard to pinpoint the exact API's users may want. It has now been almost 3 years since appmodule interfaces were introduced and we have learned a lot on how to simplify things.

There is ongoing work with the core api and runtime modules in order to handle lots of the wiring. There will be a migration story, but there are users that may want to take longer to migrate instead of all at once. For these users it makes sense to spend a few days cleaning up the old apis to make it more ergonomic. Many of the changes would be minimal and could be done in a backwards way

On top of the APIs of creating modules, there are other areas where users could benefit from some cleanup.

Some ideas are:

I'd love to hear from @ValarDragon @ethanfrey @jackzampolin on other things they would like to see. Then we can add it to the tracking list:

Focus list:

As per the interviews with chain devs, the following issues have been created:

Exhaustive list:

alexanderbez commented 2 years ago

Love to see this epic getting started, but it's paramount that we have clearly documented proposals and the motivation for them. We also might want to reference ADR-061 here too.

robert-zaremba commented 2 years ago
  1. More DevRel persons (they are really needed to grow the dev community 10x and get 2x more contributors and increase 5x the quality -> more users, more devs usually leads to more usability).
    • Cosmos community is growing, but dev support is not, it's at bare minimum if any.
  2. Testability: https://github.com/cosmos/cosmos-sdk/issues/7362 (this issue is not fully solved). Current pain points:
    • lack of isolation in tests
    • lack of proper isolation in unit tests tests. Many, many tests "marked" as unit are integration tests
    • better mocking patterns for unit tests
    • integration tests have too much "hardcoded" specification, it's almost impossible to customize them. Imagine that an SDK users will change some core parameters (eg fees) -> then all builtin sim tests will fail.
    • Way too much copy paste between the tests. We need well organized test data directory (test fixtures) and reusable test setup.

image

alexanderbez commented 2 years ago

We're literally doing most of this now. The team has been working hard and diligently on improving tests. See the improvements we've made in mocking, dependency isolation, etc...I encourage you to actually spend time looking over the recent testing related PRs the team has worked hard on.

tomtau commented 2 years ago

A migration to the standard Protobuf JSON encoding is also something worth considering -- see https://github.com/cosmos/cosmos-rust/issues/83 for the context

tac0turtle commented 1 year ago

Carrying on from what Robert mentioned, we should document unit tests and mocks in order to educate users. For integration tests we should create a framework where all that is needed are routers. This would enable modules to write tests without needing to import unneeded modules. For example, if someone is testing bank via integration tests, they shouldn't need to import staking, but only need auth to run integration tests.

Once we have the integration framework it is easy to extend this to a module level benchmark framework that works with a store package to simulate real life scenarios.

To me this is a huge pain point of users, there are many different ways to write test because we don't have a framework for this.

cc @itsdevbear

julienrbrt commented 1 week ago

Most of these have been implemented. The rest is documentation related, so I have linked them in a different issue. Let's use the board as well for Dev UX issue tracking.