Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Reduce packages coupling #7767

Closed
9 tasks
robert-zaremba opened this issue Oct 30, 2020 · 6 comments
Closed
9 tasks

Reduce packages coupling #7767

robert-zaremba opened this issue Oct 30, 2020 · 6 comments
Labels
T: Dev UX UX for SDK developers (i.e. how to call our code) Type: Code Hygiene General cleanup and restructuring of code to provide clarity, flexibility, and modularity.

Comments

@robert-zaremba
Copy link
Collaborator

robert-zaremba commented Oct 30, 2020

Summary

This is a meta issue to track and solve tight coupling between packages, notably:

  • core importing x/*
  • simapp
  • simapp "master config".

Description

Coupling is a source of the evil in many projects. Though it is helpful at the beginning, because we put things together and can iterate faster. Once the project grows and goes out of few packages level coupling start to be problematic. Usually the bigger a project is, the worse effect of coupling we have. The problems grow exponentially, because one change can induce a waterfall of other changes or even problems.

Items


For Admin Use

  • Not duplicate issue
  • Appropriate labels applied
  • Appropriate contributors tagged
  • Contributor assigned/self-assigned
@robert-zaremba robert-zaremba added Type: Code Hygiene General cleanup and restructuring of code to provide clarity, flexibility, and modularity. T: Dev UX UX for SDK developers (i.e. how to call our code) labels Oct 30, 2020
@robert-zaremba
Copy link
Collaborator Author

I had a look at the Band Protocol code, and it seams that they found fine design for to packages organization and app creation.

@alexanderbez
Copy link
Contributor

I had a look at the Band Protocol code, and it seams that they found fine design for to packages organization and app creation.

Would you like to elaborate @robert-zaremba?

core importing x/*

What is "core"?

@robert-zaremba
Copy link
Collaborator Author

core SDK packages are packages which are not in x/* and not a simapp.

Ideally, core should be self contained. I a significant amount of time in #7318. Moving things creates new import cycles. Also, there are many structures related to auth which are spanned across packages. This caused some hacks in the SDK.

Similarly EncodingConfigs, especially the MakeTestEncodingConfigs. It's at the center of many tests. Moreover, even in single test context we have few codec objects, because we don't manage them properly. There should be only one codec instance in one "runtime".

Finally, we mix a testing functions in the production packages. I already cleaned some parts when doing the bech32 PK removal.

@alexanderbez
Copy link
Contributor

Ideally, core should be self contained.

Yes, as much as possible!

What does Band do differently that you'd like to adopt?

@robert-zaremba
Copy link
Collaborator Author

It feels less messy then the simapp.

@tac0turtle
Copy link
Member

part of app wiring we are doing now

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
T: Dev UX UX for SDK developers (i.e. how to call our code) Type: Code Hygiene General cleanup and restructuring of code to provide clarity, flexibility, and modularity.
Projects
None yet
Development

No branches or pull requests

3 participants