Project Admin: Our Technical Approach
On this page, we delve into our technical approach, highlighting how we organise our work, facilitate collaboration between frontend and backend teams, and leverage GitHub for effective project management.
At the heart of our system is a well-defined API specification. This specification outlines the endpoints, request/response formats, and data schemas, serving as the contract between frontend and backend components. By adhering to this specification, teams can work independently on their respective tasks while ensuring seamless integration at the API level.
To promote modularity and scalability, we adopt a microservices architecture. This means that instead of building the full-load component-dependent software, we break it down into smaller, more manageable parts called microservices. Microservices, in our case, would include things like the varying models, the controller, and the data pipeline for managing data in our database. They can function independently and are put together and the end to form our application.
Each functional component of our system is encapsulated within a microservice, responsible for a specific set of tasks or features. This approach allows both frontend and backend to develop, deploy, and scale their components independently, reducing dependencies and improving overall system resilience.
To facilitate real-time communication and decouple components, we employ an event-driven architecture. Events are used to trigger actions across services, enabling asynchronous communication and scalability. This is exceptionally important in our frontend as we anticipated large amounts of components requesting data at the same time. With asynchronous communications, we reduce load time and make our product more efficient.
Evidently, GitHub serves as the central hub for our project's version control, collaboration, and project management. We've established an organisation dedicated to our project, which hosts the main repository containing our codebase.
To facilitate individual contributions while maintaining a centralised codebase, each team member forks the organisation's repository to their personal GitHub account. We followed this forking approach for a couple of reasons:
-
Development Autonomy: Team members can work independently within their forked repositories, exploring new features or making changes without affecting the stability of the main codebase. This gives our team members more freedom in developing their components without worrying about ruining the main codebase.
-
Structured Contribution Workflow: When team members are ready to contribute their changes, they create pull requests from their forked repositories to the main organisation repository. Other team members can then evaluate the changes for quality and alignment with project objectives before being merged into the main codebase.
Within their forked repositories, team members also follow a structured branching strategy to manage their work effectively. When starting work on a new feature or task, they create a dedicated feature branch from the main branch. This branching approach isolates their changes, making it easier to track progress and collaborate with other team members.
Our technical approach emphasises collaboration, modularity, and scalability. By leveraging API specifications, microservices architecture, and event-driven communication, we hope to deliver a robust and flexible system that meets the needs of our data science project.