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.

Sign up for GitHub

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

Jump to bottom

Create a REST API #28

Open
mrhappyasthma opened this issue May 14, 2021 · 5 comments
Open

Create a REST API #28

mrhappyasthma opened this issue May 14, 2021 · 5 comments
Labels
enhancement New feature or request open question Further information is requested

Comments

@mrhappyasthma
Copy link
Owner

This will be useful for headless usage of the calculations on the site.
@mrhappyasthma
Copy link
Owner Author

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.

mrhappyasthma added a commit that referenced this issue Jun 9, 2021
@mrhappyasthma
Refactor data fetching into its own file.
9098905 
This is the first step toward #28
@mrhappyasthma mrhappyasthma added enhancement New feature or request open question Further information is requested labels Jul 4, 2021
@mrhappyasthma
Copy link
Owner Author

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.)

@mrhappyasthma
Copy link
Owner Author

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.

@kocielnik
Copy link
Contributor

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:)

@kocielnik
Copy link
Contributor

While fiddling with this, I've identified 4 perspectives I'd appreciate your feedback on (#78):

  1. Replace CircleCI config with GitHub Actions config.
  2. Move requirement specification to pyproject.toml.
    • The file format seems to be the current recommendation (link). The build tool can be chosen freely - does not have to be the Poetry tool used here.
  3. Move some code from main.py to the library part for easier testing.
  4. List .envrc in .gitignore.
    • Tool-specific file (Direnv). Simplifies development by entering and unloading the virtual environment on the fly on directory enter/leave.

mrhappyasthma pushed a commit that referenced this issue Jul 1, 2024
@kocielnik
#28: Cleaning up a little to enable unit-testing API code. (#78)
016d944 
* Add an API test.

* Try to enable GitHub Actions.

* Try to remove the Werkzeug warning.

* Get a real quote.

* Rename package to src for now.

While pyproject.toml must contain the package name, using a name other
than "src" would require cascading changes to the submodules.

Let's leave that for a later stage, if required.

* Allow Python 3.10.

* Allow Python ^3.8.

Recent Flask requires ^3.8.

* Skip checking for requirements.txt (extra step).

* Remove requirements.txt.

* Add PyTest as a plain dependency.

* Specify Mark as the author.

* Refactor: Move server logic from main.py to src/server.py.

* Debug: Print current values.

* Remove a debug print.

* Remove CircleCI config.

Configured GitHub Actions instead.

If that isn't equivalent, we can revert.

* Untrack .envrc.

* Remove .envrc.

* Add PyLint exclusions for most common warnings.

These specific warnings were so numerous they obscured the code.

Before anyone gets to cleaning these warnings [1], let's disable them
for now just to make reading the code easier.

[1]: *If* they should ever be cleaned at all.

* Move test_api to tests/.

* Remove unneeded mock.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
enhancement New feature or request open question Further information is requested
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@mrhappyasthma @kocielnik