Backend of stocknear - Open Source Stock Analysis
Go to file
MuslemRahimi 0730b99b11 bugfixing
2024-09-20 17:00:03 +02:00
.github Update FUNDING.yml 2024-09-11 12:50:06 +02:00
app bugfixing 2024-09-20 17:00:03 +02:00
fastify increase timeout of ws 2024-09-19 20:49:30 +02:00
.gitattributes update endpoint 2024-05-26 22:28:08 +02:00
.gitignore add loggin to cron job 2024-07-09 17:29:30 +02:00
LICENSE Update LICENSE 2024-06-02 18:55:37 +02:00
README.md Update README.md 2024-07-07 22:45:19 +02:00
requirements.txt add corporate lobbying cron job 2024-08-06 22:24:50 +02:00

Open Source Stock Analysis for Data Freaks

Homepage | Discord

GitHub Repo stars

Techstack

This is the codebase that powers stocknear's backend, which is an open-source stock analysis & community platform.

Built with:

Getting started

Follow the instructions below to run stocknear locally on your machine.

Prerequisites & Resources

  • Python 3.x (Recommended: 3.10.12 or higher)

  • Pip (Python package installer)

  • PocketBase (Download and install from: https://pocketbase.io/

  • Download schemas, databases and configurations files:

    • stocks.db [TODO - add link]
    • crypto.db [TODO - add link]
    • institute.db [TODO - add link]
    • json.zip folder [TODO - add link]
    • pocketbase schema [TODO - add link]

Installation

  1. Set up virtual env:

python -m venv env

source env/bin/activate # On macOS/Linux

.\env\Scripts\activate # On Windows

  1. Install dependencies:

pip install -r requirements.txt

Run

  • Pocketbase: ./pocketbase serve
  • Fastify: npm start
  • FastAPI: uvicorn main:app --reload

Contributing

Stocknear is open-source software and you're welcome to contribute to its development.

The core idea of stocknear shall always be: Fast & Simple.

If want to contribute to the codebase please follow these guidelines:

  • Refactoring slow code into fast code is a huge plus!
  • Reducing complexity and increasing simplicity/readability is a huge plus!
  • Anything you claim is a "speedup" must be benchmarked. In general, the goal is simplicity, so even if your PR makes things marginally faster, you have to consider the tradeoff with maintainablity and readablity.
  • If your PR looks "complex", is a big diff, or adds lots of lines, it won't be reviewed or merged. Consider breaking it up into smaller PRs that are individually clear wins. A common pattern I see is prerequisite refactors before adding new functionality. If you can (cleanly) refactor to the point that the feature is a 3 line change, this is great, and something easy for us to review.

Support ❤️

If you love the idea of stocknear and want to support our mission you can help us in two ways:

  • Become a Pro Member of stocknear to get unlimited feature access to enjoy the platform to the fullest.
  • You can donate money via Ko-fi to help us pay the servers & data providers to keep everything running!