- Python >=3.10
- Docker
Additionally, in order to be able to use the platform to the fullest, install libmagic
and ffmpeg
.
sudo apt-get install libmagic1
sudo apt-get install ffmpeg
To run the backend for this project locally, follow these steps:
- Install poetry. This can be done by following the instructions on https://python-poetry.org/docs/.
- Navigate to the backend directory in your terminal.
- Run
poetry install
to install all dependencies into the current environment. - Copy .env.template to a .env, and fill in the required values. The required values can be found in
backend/README.md
. - Run
docker compose up -d
to start the required dependencies. - Run
poetry run python init_db.py
to run the migrations and setup the environment. - Run
poetry run start
to start the project for development. - (Optional) Run
poetry run arq src.intric.worker.arq.WorkerSettings
to start the worker.
To run the frontend for this project locally, follow these steps:
- Install node >= v20 (https://nodejs.org/en)
- Install pnpm 8.9.0 (https://pnpm.io/)
- Navigate to the frontend directory in your terminal
- Run
pnpm run setup
- Navigate to
frontend/apps/web
and setup the .env file using the .env.example. You can learn more about the environment variables infrontend/apps/web/README.md
- Run
pnpm -w run dev
to start the project for development. - Navigate to
localhost:3000
and login with email[email protected]
and passwordPassword1!
(provided you have run the setup steps for the backend).
The project is configured to use a devcontainer, which allows you to develop in a consistent environment using Visual Studio Code and Docker. Follow these steps to get started:
-
Install Prerequisites:
- Ensure you have Docker installed on your machine.
- Install Visual Studio Code and the Remote - Containers extension.
-
Copy Environment Files:
- Before starting development, you need to set up your environment files:
# In the backend directory cp .env.template .env # In the frontend/apps/web directory cp .env.example .env
- Remember to update these .env files with appropriate values.
- Before starting development, you need to set up your environment files:
-
Open the Project in a Devcontainer:
- Open the project folder in Visual Studio Code.
- When prompted, or by clicking on the green icon in the bottom-left corner, select "Reopen in Container".
- This will build the devcontainer as defined in
.devcontainer/devcontainer.json
and.devcontainer/docker-compose.yml
.
-
Accessing Services:
- The devcontainer setup will automatically forward ports 3000 and 8123, allowing you to access the frontend and any other services running on these ports.
-
Post-Create Commands:
- After the container is created, the
postCreateCommand
specified in.devcontainer/devcontainer.json
will run, setting up the environment.
- After the container is created, the
-
Developing:
- You can now develop as usual within the container. The environment will have all necessary dependencies installed and configured.
Important Notes:
-
Database migrations are not run automatically. After the container is created, you'll need to run:
cd backend poetry run python init_db.py
-
You'll need to manually start both the backend and frontend services in separate terminal windows:
For the backend:
cd backend poetry run start
For the frontend:
cd frontend pnpm run dev
Running the frontend and backend in separate terminal windows gives you better control over each service's lifecycle. This makes it easier to restart individual services when needed, such as after installing new dependencies or when troubleshooting issues.
-
Stopping the Devcontainer:
- To stop the devcontainer, simply close Visual Studio Code or use the "Remote - Containers: Reopen Folder Locally" command.
This setup ensures that all developers work in the same environment, reducing "it works on my machine" issues.
Coming soon.
The architecture for each feature strives to look like this:
feature_x/
├── api/
│ ├── feature_x_models.py
│ ├── feature_x_assembler.py
│ └── feature_x_router.py
├── feature_x.py
├── feature_x_repo.py
├── feature_x_service.py
└── feature_x_factory.py
An example of this can be seen in the Spaces
feature.
The main class, the main domain object. Domain logic pertaining to how the feature works should live here.
Dependency inversion of database dependency. Should input a Feature_x
class (or an id
) and return that same class.
Responsible for connecting this domain object with other related ones.
Factory class. Creates the domain object.
Specifies the endpoints.
Definition of the API schema.
Translates domain objects to the API schema, allowing for the schema to change without affecting the shape of the domain object.
We use a dependency injection framework to handle dependency injection for us. This framework creates all the other necessary classes, and handles their inter-dependency. This is typically done in the router.
Add the router in the main router in order to connect the endpoints to the application.
While this is what we are striving towards at the moment, this is always subject to change.
We use alembic for our database migrations.