You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Using SDKs and official APIs is nice and very easy to read/implement/maintain, but when using requests I think wrapping those requests in a client could make life easier on future changes.
Same goes to the official APIs and SDKs but those are much less of a pain when reading the code itself.
Creating a client.py file or data_class/client folder seems right for me, Ideally when something changes in the API itself you'd want your code to work properly, when you wrap it up in your own class you need to change much less code in the data source itself and only touch the client side.
As for making the code safer - adding this folder could be a nice place to start writing tests and mocks for each client but that's a whole other topic.
The text was updated successfully, but these errors were encountered:
Itaykal
changed the title
Suggestion: wrap clients in as client.py
Suggestion: wrap data_source clients
Mar 30, 2023
Using SDKs and official APIs is nice and very easy to read/implement/maintain, but when using requests I think wrapping those requests in a client could make life easier on future changes.
Same goes to the official APIs and SDKs but those are much less of a pain when reading the code itself.
Creating a client.py file or data_class/client folder seems right for me, Ideally when something changes in the API itself you'd want your code to work properly, when you wrap it up in your own class you need to change much less code in the data source itself and only touch the client side.
As for making the code safer - adding this folder could be a nice place to start writing tests and mocks for each client but that's a whole other topic.
The text was updated successfully, but these errors were encountered: