This is the microservice for the FamTrust project that focuses and handles the core functionalities of the project. The core functionalities include:
- Family Groups and Membership Management
- Family Accounts Management
- Family Transactions Management
- Fund Requests Management
Live link is at https://core.famtrust.biz/api/v1
Doc link at https://documenter.getpostman.com/view/14404907/2sA3s3HWhp
Before setting up the project locally, ensure you have the following prerequisites installed:
- Python (>=3.11.4)
- Django
- Django Rest Framework
- A Database System (e.g., Postgres, MySQL, SQLite) - Django Database Installation
Ensure you follow the env_file_template to set the required variables
ENV=
FAMTRUST_SECRET_KEY=
DB_NAME=
DB_ENGINE=
DB_USER=
DB_PASSWORD=
DB_HOST=
DB_PORT=
EXTERNAL_AUTH_URL=
API_VERSION=
PRODUCTION_URL=
PAGE_SIZE=
MAX_PAGE_SIZE=
-
Clone the repository:
git clone https://github.com/InternPulse/famtrust-backend.git -
Change into the parent directory:
cd famtrust-backend -
Set up a virtual environment:
python3 -m venv venv -
Activate your virtual environment:
source venv/bin/activate -
Install the Python dependencies:
pip install -r requirements.txt -
Create a .env file and set necessary secret keys below:
-
Apply migrations to create the database schema:
python3 manage.py migrate -
Start the development server:
python3 manage.py runserver
The API should now be running locally at http://localhost:8000/api/v1.
- dev -> pr this branch for everything
backendrelated - main -> don't touch this branch, this is what is running in production!
famtrust-backend is open to contributions, but I recommend creating an issue or replying in a comment to let us know what you are working on first that way we don't overwrite each other.
- Clone the repo
git clone https://github.com/InternPulse/famtrust-backend.git. - Open your terminal & set the origin
branch:
git remote add origin https://github.com/InternPulse/famtrust-backend.git - Pull origin
git pull origin dev - Create a new branch for the task you were assigned to,
eg
TicketNumber/(Feat/Bug/Fix/Chore)/Ticket-title:git checkout -b BA-001/Feat/Sign-Up-from - After making changes, do
git add . - Commit your changes with a descriptive commit message :
git commit -m "your commit message". - To make sure there are no conflicts, run
git pull origin dev. - Push changes to your new branch, run
git push -u origin feat-csv-parser. - Create a pull request to the
devbranch notmain. - Ensure to describe your pull request.
- If you've added code that should be tested, add some test examples.
Under any circumstances should you merge a pull request on a specific branch to the dev or main
branch
| Type | Description | |
|---|---|---|
| feat | Features | A new feature |
| fix | Bug Fixes | A bug fix |
| docs | Documentation | Documentation only changes |
| style | Styles | Changes that do not affect the meaning of the code (white-space, formatting, missing semi-colons, etc.) |
| refactor | Code Refactoring | A code change that neither fixes a bug nor adds a feature |
| perf | Performance Improvements | A code change that improves performance |
| test | Tests | Adding missing tests or correcting existing tests |
| build | Builds | Changes that affect the build system or external dependencies (example scopes: gulp, broccoli, npm) |
| ci | Continuous Integrations | Changes to our CI configuration files and scripts (example scopes: Travis, Circle, BrowserStack, SauceLabs) |
| chore | Chores | Other changes that don't modify, backend or test files |
| revert | Reverts | Reverts a previous commit |
Sample Commit Messages
chore: Updated README file:=choreis used because the commit didn't make any changes to the backend or test folders in any way.feat: Added plugin info endpoints:=featis used here because the feature was non-existent before the commit.