EPIC: Dev UX

[tac0turtle]

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:

• Client api cleanup and ergonomic fixes
• this has come up but would need better insight into how this should progress cc @jackzampolin
• Codegen all cli and grpc for modules to avoid needing to write extra boiler plate
• Separate internal external logic with a internal package in modules

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:

• Update Upgrade documentation and guides #11504
• EPIC: make guarantees around query responses #13041
• define public store api #12926
• Create a guide for proto.Message String() methods #12908
• Investigate how to speedup SDK chain build times #12805
• Can we change ImportGenesis & ExportGenesis to return a proto.Message interface #12642
• Refactor to delete every modules keeper/hooks.go file #12079
• Automate EventTypeMessage inclusion in every message execution #11868
• add back tx/encode endpoint #10856
• Document best practices for data serialization #7985
• Make helper functions for adding accounts to genesis state. #12091
• SDK Gotcha Doc #13171

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

• docs: add a note on sources of non-determinism for module developers #10562
• Improve IAVL Viewer iavl#567
• EPIC: Create buf registry for each extracted module #13363
• Genesis Documentation  #1727
• Cosmovisor fetch-upgrade command #10910
• ...

Exhaustive list:

• T: Dev UX UX for SDK developers (i.e. how to call our code)

[alexanderbez]

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]

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: Improve testing DevX #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.

[alexanderbez]

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]

A migration to the standard Protobuf JSON encoding is also something worth considering -- see cosmos/cosmos-rust#83 for the context

[tac0turtle]

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]

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.