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

Expand websocket adapter, ensure connections/disconnections can be done dynamically, establish better pattern for dynamic subscriptions for use in other adapters #277

Open
timkpaine opened this issue Jun 12, 2024 · 3 comments
Labels
adapter: general Issues and PRs related to input/output adapters in general adapter: websocket Issues and PRs related to our websocket adapter type: enhancement Issues and PRs related to improvements to existing features

Comments

@timkpaine
Copy link
Member

timkpaine commented Jun 12, 2024

Many adapters have static, wiring-time connection requirements, e.g. you need to provide a url or channel or topics at wiring time and cant make new connections dynamically. Starting with the websocket adapter where it is more (most?) relevant, we should establish a better pattern for dynamic subscriptions. This will be of particular importance in the upcoming redis adapter.

We may want to develop a common structure for subscriptions, though it will like have implementation-dependent details. As a simple example for websockets:

class ConnectionRequest(struct):
    url: string
    action: ActionType # Connect, Disconnect, Ping, etc
    persistent: bool  # e.g. 
    on_connect_payload: Any
   ...

Then adapters will have the following structure:

%%{init: {'flowchart': {'defaultRenderer': 'elk'}}}%%

flowchart LR
    requests["Requests for new connections/paths"]
    data_from["Data from existing connections/paths"]
    data_to["Data to connections/paths"]
    adapter["Adapter/Manager"]
    status["Status or Status of Requests"]
    requests --> adapter
    data_to --> adapter
    adapter --> status
    adapter --> data_from
Loading

For redis its even more complicated, but still the same overall pattern

%%{init: {'flowchart': {'defaultRenderer': 'elk'}}}%%

flowchart LR
    key_and_data_to_write["Key + Data to write"]
    key_hash_data_to_write["Key/Hash + Data to write"]
    key_to_read["Key to read"]
    key_and_hash_to_read["Key/Hash to read"]
    key_to_sub["Key to sub"]
    adapter["Adapter/Manager"]
    data["Data from read request"]
    data_from_sub["Data from sub"] 
    status["Status or Status of Request"]
    key_and_data_to_write --> adapter
    key_hash_data_to_write --> adapter
    key_to_read --> adapter
    key_and_hash_to_read --> adapter
    key_to_sub --> adapter
    adapter --> status
    adapter --> data
    adapter --> data_from_sub
Loading
@timkpaine timkpaine added adapter: general Issues and PRs related to input/output adapters in general adapter: websocket Issues and PRs related to our websocket adapter labels Jun 12, 2024
@timkpaine timkpaine added the type: enhancement Issues and PRs related to improvements to existing features label Jun 19, 2024
@Roh-codeur
Copy link

Upvote. this would be quite useful in my project pls

@Roh-codeur
Copy link

hi, is this something being considered please?

@timkpaine
Copy link
Member Author

Yep!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
adapter: general Issues and PRs related to input/output adapters in general adapter: websocket Issues and PRs related to our websocket adapter type: enhancement Issues and PRs related to improvements to existing features
Projects
None yet
Development

No branches or pull requests

2 participants