Overview

This is the main Cubed project, and usually where developers will start. This project is built on Django with a React frontend, and controls the database structure via django migrations, the frontend dashboard via react, and our commands system via Conductor. We support the react frontend via the Tastypie API which has our own functionality built in to allow aggregation of data.

With multiple applications combined into one project, this means when you vagrant up this repo, in 1 server you will be able to: add migrations to any part of Cubed, add features or build commands for clients, base, seopt, control, conductor etc...

Dashboard

Is split into 2 sections: "frontend" (js/html), and "backend-api" (python/tastypie).

Frontend

Is built in React and uses TypeScript. All widgets/components should have a matching Storybook and/or Playwright. We also call this our "frontend" or simply "the dash". Users log in and can configure their Cubed account and see all our data via reports. The frontend talks to the database via our "backend api".

Backend API

This is build on Tastypie, which allows out of the box filtering via query params. We use the Tastypie base ModelResource class for all simple RESTful request (get, post, put, delete) which is mainly the config section. We have our own CubedReportResource which extends this base class and adds our own functionality to deal with "group by" and aggregation per field/column.

Control

This is the real backend to the project and where Django sits. From here we can run any command to process/handle data, but it is primarily used for Django's model design and migration functionality. Any new table added to Cubed is done so via Django's model system, and is added/updated in a client DB by running our bespoke command migrate_client.

There are a handful of Django views that the frontend interacts with as they need to do more than just fetch data. These are usually so we can talk to external APIs and handle OAuth2 flows.

Conductor

This is our commands system. When we say "crons" we are referering to commands that run at night for each client, and processes their data in their own DB. Each command Conductor runs can be run manually from Control, however the idea of Conductor is that it runs commands on its own, and handles any errors/retry issues.

The main benefit from Conductor is that all accounts run at the same time, and any commands that can be run in parallel are done so.