feat: add exponential retry mechanism

[im-perativa]

closes #91

This PR

• Adds HTTP Exponential Retry mechanism to novu client
• Adds relevant tests
• Adds UUID based Idempotency Headers
• Update docs
• Can be used with existing custom requests.Session
• Refer to the go-lang library to keep the method signature and configuration the same

Sample usage:

from novu.api import EnvironmentApi
from novu.api.base import RetryConfig

url = "https://api.novu.co"
api_key = "<API_KEY>"

# # List existing environments
novu = EnvironmentApi(
    url, api_key, retry_config=RetryConfig(initial_delay=1, wait_min=2, wait_max=100, retry_max=4)
).list()

[ryshu]

I haven't looked in detail but it seems good to me in terms of functionality.

On the other hand, I am against adding a new dependency for clients while these functionalities already exist in the library that we use. See the following links:

• https://docs.python-requests.org/en/latest/user/advanced/#example-automatic-retries
• https://urllib3.readthedocs.io/en/stable/reference/urllib3.util.html#urllib3.util.Retry

[im-perativa]

I haven't looked in detail but it seems good to me in terms of functionality.

On the other hand, I am against adding a new dependency for clients while these functionalities already exist in the library that we use. See the following links:

* https://docs.python-requests.org/en/latest/user/advanced/#example-automatic-retries

* https://urllib3.readthedocs.io/en/stable/reference/urllib3.util.html#urllib3.util.Retry

Thanks for the feedback @ryshu . I was about to use the requests + urllib3 Retry before but as mentioned here I realized it would interfere/confusing for the already provided custom session options (only in python SDK) .

Afaik, they also provide less customization / parameters so it will make the configuration differ from the existing method in go SDK.
Would that be okay?

[ryshu]

I haven't looked in detail but it seems good to me in terms of functionality.
On the other hand, I am against adding a new dependency for clients while these functionalities already exist in the library that we use. See the following links:

* https://docs.python-requests.org/en/latest/user/advanced/#example-automatic-retries

* https://urllib3.readthedocs.io/en/stable/reference/urllib3.util.html#urllib3.util.Retry

Thanks for the feedback @ryshu . I was about to use the requests + urllib3 Retry before but as mentioned here I realized it would interfere/confusing for the already provided custom session options (only in python SDK) .

Afaik, they also provide less customization / parameters so it will make the configuration differ from the existing method in go SDK. Would that be okay?

For me, this is precisely what is interesting:

• if someone provides a session, we do nothing here (apart from offering them our retry configuration in the documentation)
• if no one provided session, we default initialization with retry configuration (to apply exponential retry on every SDK by default)

For me, there is no problem with the fact that we do not have all the functionalities of the GO lib as long as the behavior (exponential retry via the backoff_factor) is well implemented so as not to retry too often on the server.

WDYT @Cliftonz ?

[im-perativa]

I would like to know your opinion before changing this pr @Cliftonz

[Cliftonz]

@im-perativa I agree with ryshu the backoff strategy is important.

I do want to specify that by default retry should not be on, as we want users to specifically opt into this and it changes the priority of Novu from availability to consistency.

@ryshu what features are you not able to do 1:1?

[ryshu]

Ok for the opt-in instead off opt-out.

@im-perativa Can you clarify the missing functionnality implemented in go sdk ?

[unicodeveloper]

Please, how can we move forward here? @ryshu

[ryshu]

Please, how can we move forward here? @ryshu

Hi @unicodeveloper,

Reply pending from @im-perativa in fact

[im-perativa]

@ryshu Sorry I'm not sure if I will have the capacity to modify it in timely manner so that no external dependencies is added, nor do I think it will be an elegant solution. Feel free to reassign the issue or modify it