The Refactor

[dodo920306]

Let's face it: the current state of this project’s code is not so good.

Contributions over time have lacked consistency, leading to duplicated implementations and a fragmented structure that makes maintenance and development difficult.

The combination of Python, Django, and object-oriented design has introduced unnecessary complexity, and without long-term technical stewardship, the project has become hard to extend.

Another pressing issue is the number of long-standing bugs. For a project that has been in existence for over six years, there remain issues that ideally should have been addressed very early on. Many of these are not superficial problems that tools or automated testing could easily detect, but deeper logical flaws that only become evident when the affected code paths are used.

Additionally, it seems that the project has not fully embraced the design principles of Django REST Framework (DRF). For example, serializers are often used only for traffic handling, while much of the core business logic resides in views.py, which goes against DRF’s intended design practices.

To summary, a refactor is inevitable, and to make sure I’m not just another person who criticizes without acting, I’ll do it myself.

[yeasy]

@YoungHypo suggest we create a new branch for this refactor work.

[dodo920306]

@YoungHypo suggest we create a new branch for this refactor work.

I just realized that I myself can also create a new branch in this repo. Therefore, I created a new branch called lab/kirin-refactor as a new target for this PR.

Feel free to suggest another branch name.

[dodo920306]

The changes here have been split into 9 PRs:

1. Remove Celery and its related tasks #741
2. Restructure backend into separate Django applications #742
3. Implement Channel and Chaincode core functionality #743
4. Reorganize Docker files and infrastructure #744
5. Frontend authentication and integration fixes #745
6. Improve code quality and linting fixes #746
7. Enhance sidebar links #747
8. Extend Chaincode functionality #748
9. Modernize frontend component s and reduce codes #749

[dodo920306]

With the first interaction with a chaincode via Hyperledger Cello done on my PC, I hereby proudly announce that now Hyperledger Cello API Engine has the very basic ability to interact with chaincodes after a1f9e92 🥳!

This definitely took a lot longer than expected, and the functionality is definitely not mature enough now ---- it is currently inaccessible via dashboard.

@yeasy

[dodo920306]

Update for this PR:

After several meetings and discussions, I officially retract some of my comments in #735 (comment) and acknowledge that agents do indeed have their necessity.

However, I also raised my concerns during the meetings — namely, that the logic for interacting with blockchain nodes on the main branch is almost entirely concentrated in the api-engine. The agent, acting as a proxy within each organization's cluster, still relies on the api-engine — which exists independently of all clusters — to perform operations. This greatly reduces the necessity of installing agents in each cluster, and also calls for a rethinking of the network layer design.

Subsequently, @yeasy proposed moving all current blockchain interaction logic into the agent, allowing the agent to handle all operations. This also aligns with the original intention of Hyperledger Cello: to move blockchain-specific operations into agents, enabling users to support various blockchain projects simply by swapping agents.Fortunately, after this refactoring, user request handling is decoupled from business logic to the maximum extent (i.e., a view-service layered design). This makes it relatively easier to extract service logic and insert it into a standalone agent project compared to the main branch, so implementing a new agent might be easier than explained during the meetings.

In any case, reintegrating the decoupled agent will be the next and final stage of this refactoring. Hopefully, this process will go more smoothly this time.