Open mrhappyasthma opened 3 years ago
A good first step here would be to refactor all the URL fetches to occur with a single method call that returns the dictionary of final results for the UI.
Then the URL handler can just call this function and return the result.
Separate code could then call into this function manually for things like APIs.
Code is now separated, but feasibility is limited by AppEngine. I'd have to rate limit the API and provide API keys, which feels like a lot of work for minimal payout.
It's easiest to just clone the code locally and execute the DataFetcher calls manually. (As a short-term workaround.)
I added a separate repo to do this: https://github.com/mrhappyasthma/Rule1-StockScreener
Coding up an API (even if it's not enable for now due to cost limitations) may still be a nice stretch goal.
I view the API-like endpoint you created in 2021 as a convenient test interface for the computing logic.
While the test methods calling particular classes would need to be updated in case the internal logic changes, such tests would ensure no update would be needed as long as the output (dict
) remains the same.
This may be a totally unhelpful idea.
I just wanted to let you know I've been experimenting with it, and the test code is here.
Credit: Thinking of such tests was possible for me only thanks to the internal "endpoint" you created in 2021:)
While fiddling with this, I've identified 4 perspectives I'd appreciate your feedback on (#78):
pyproject.toml
.
main.py
to the library part for easier testing..envrc
in .gitignore
.
This will be useful for headless usage of the calculations on the site.