Planning for refactor as a library #48
Labels
No labels
Blocked
Bounty
$100
Bounty
$1000
Bounty
$10000
Bounty
$20
Bounty
$2000
Bounty
$250
Bounty
$50
Bounty
$500
Bounty
$5000
Bounty
$750
MoSCoW
Could have
MoSCoW
Must have
MoSCoW
Should have
Needs feedback
Points
1
Points
13
Points
2
Points
21
Points
3
Points
34
Points
5
Points
55
Points
8
Points
88
Priority
Backlog
Priority
Critical
Priority
High
Priority
Low
Priority
Medium
Signed-off: Owner
Signed-off: Scrum Master
Signed-off: Tech Lead
Spike
State
Completed
State
Duplicate
State
In Progress
State
In Review
State
Paused
State
Unverified
State
Verified
State
Wont Do
Type
Bug
Type
Discussion
Type
Documentation
Type
Epic
Type
Feature
Type
Legendary
Type
Support
Type
Task
Type
Testing
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Blocks
You do not have permission to read 1 dependency
Reference: clevermicro/amq-adapter-python#48
Loading…
Add table
Add a link
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
With the assumption in mind, just like java, we need to offer a proper library API for the downstream users. Just like any client library, we should expose internal functions as individual methods so the user can have the maximum freedom to do whatever they want. For now, the python code is more like a giant block of logic that cannot be controlled by external requests.
Considering none of us are python experts, thus this ticket will focus on designing the refactor plan. Based on python and related libraries, we need to figure out what is the best way to expose control to various internal features like route discovery, handling RabbitMQ messages (RPC calls and amq adapter message), sending rpc calls or messages, etc.
The ticket will include the efforts to know/learn the related python library, doing test and simple demos to decide the best way for exposing control point for async processes, and eventually creating a document and a serial of tickets for the refactor.
Most of the code should be reused, since it's a refactoring, but new code should be added to properly encapsulate the internal logic and offer a friendly interface for the users. For example, we could package all related fields into a context object instead of asking for a bunch of parameters in every method.