robertbetts / nuropb Goto Github PK

1. Correct the current logic that an ssl context is not set when ssl parameters are input.
2. Improve the current logic to reference the parameter ssl: bool to determine of ssl is to be configured or not.

To initialize the a client instance of the library as a minimum you'd do the following.

from nuropb.rmq_api import RMQAPI
amqp_url = "amqp://guest:guest@localhost:5672/nuropb"
client_api = RMQAPI(
        amqp_url=amqp_url,
)
await client_api.connect()

It would be very useful to be able to do the following, especially when working within notebooks

from nuropb import RMQAPI
client_api = RMQAPI()
await client_api.connect()

or even:

import nuropb
client_api = await nuropb.connect()

The ask covers two concepts:

• fewer lines of code and streamlined interfacing to the API
• Auto config with sensible defaults or system provided configuration

The imports required when using the library can be somewhat clunky.

Something like this might make things simpler, making use of reasonable default and or specified environment parameters

import nuropb
npb_api = nuropb.client_connect()

In addition for basic service usage perhaps:

import nuropb

def my_event_handler(topic, event, context, target, trace_id):
    pass

npb.api = nuropb.service_connect(
    service_name="my-test-service",
    event_subscriptions=["service-one.topic-i-like"],
    event_handler=my_event_hander,
)

Question 1: Should a nuropb service mesh connection be able to make a request to itself when instantiated as a service ?
Question 2: Should a nuropb service mesh connection be able to subscribe to event topics, that it publishes ?

This is not a debate on conceptually how should these scenarios be handled, and the opinion of the team is that answering yes in both cases is bad practice.

The consideration is whether or not to implement restrictions aimed at preventing these two scenarios, either within the code base or by introducing topic naming and exchange binding conventions that prevent circular flows. Alternatively, should the current more "open" approach continue, leaving the decision to the implementation in deciding on the approach and patterns to follow?