Planning for refactor as a library #48

New Issue

2025-05-29T08:34:35Z

hurui200320 commented

2025-05-29 08:34:35 +00:00

This ticket is a similar ticket like clevermicro/amq-adapter-java#24 for epic cleverthis/clevermicro#6. The epic itself still need more details, since we don't know how native we should achieve for adopting CleverMicro natively in R2R. For now, I assume by native, R2R will call the adapter as a library to offer endpoints in RabbitMQ, instead of writing for other frameworks and let amq adapter adopt them.

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.

> This ticket is a similar ticket like clevermicro/amq-adapter-java#24 for epic cleverthis/clevermicro#6. The epic itself still need more details, since we don't know how native we should achieve for adopting CleverMicro natively in R2R. For now, I assume by native, R2R will call the adapter as a library to offer endpoints in RabbitMQ, instead of writing for other frameworks and let amq adapter adopt them. 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.

hurui200320 added the

labels 2025-05-29 08:34:35 +00:00

hurui200320 added a new dependency 2025-05-29 08:34:49 +00:00

cleverthis/clevermicro#6 - Prepare package to entice R2R to move to micro upstream

stanislav.hejny added