6540d01175
This commit introduces several new files and updates to support SR&ED tracking and project management: - Adds a template for SR&ED tasks to standardize issue creation. - Adds a Makefile command to set up GitHub labels from a YAML file. - Adds a Makefile command to export SR&ED-eligible issues to a Markdown file. - Adds a Makefile command to create issues from a file. - Adds documentation for SR&ED tracking and development conventions. - Adds a YAML file to define GitHub labels. - Adds scripts to set up GitHub labels, export issues, and create issues from a file. - Updates the project plan to include SR&ED considerations. These changes aim to improve project organization, facilitate SR&ED claims, and streamline development workflows.
5.3 KiB
SR&ED Project Documentation - KROW Platform
This document serves as the primary record for tracking Scientific Research and Experimental Development (SR&ED) activities for the KROW project. It translates our project plan into the language of technological uncertainty and systematic investigation, as required for SR&ED claims.
Overall Technological Uncertainty
The core technological uncertainty of this project is whether a unified backend, built on the novel Firebase Data Connect service, can effectively and performantly serve a heterogeneous set of clients (a React web app and two Flutter mobile apps) while maintaining data integrity in a complex relational model (PostgreSQL). This involves overcoming challenges in schema management, SDK generation, and real-time data synchronization across platforms, for which no standard industry solution exists.
Milestone 1: Foundation & Dev Environment Setup
1.1. Technological Uncertainty
Can we establish a stable, multi-environment (dev, staging, prod) development workflow for a complex monorepo that integrates a declarative backend (Data Connect), a web frontend, and mobile frontends? The primary challenge is to create a reproducible setup that overcomes the limitations of local emulation and allows for parallel, collaborative development on a shared cloud infrastructure without conflicts.
1.2. Hypothesis
By combining a multi-environment Makefile, Firebase project aliases, and auto-generated, environment-aware SDKs, we hypothesize that we can create a streamlined and scalable development workflow. This approach should allow developers to seamlessly switch between cloud environments and ensure that all client applications (web and mobile) are always interacting with the correct backend instance.
1.3. Experimental Work
(This section can be auto-populated by running make export-issues with the appropriate filters/labels.)
[Infra] Create Multi-Env Makefile: Development of a script to manage different cloud environments, which is a non-trivial engineering task involving environment variable injection and conditional logic.[Backend] Define GraphQL Schema & Deploy to Dev: Experimentation with the Data Connect schema-to-SQL generation process to validate its capabilities, performance with relational data, and limitations.[Web/Mobile] Generate & Integrate SDKs: Systematic investigation into the interoperability of the auto-generated SDKs with modern frontend frameworks (React/TanStack Query and Flutter/BLoC).
1.4. Results & Learnings
(To be filled out upon milestone completion.)
Milestone 2: Core Feature Implementation
2.1. Technological Uncertainty
Once the foundational architecture is in place, the next uncertainty is whether the declarative nature of Data Connect is powerful enough to handle the complex business logic required by the KROW platform. Can we implement features like multi-step event creation, real-time status updates, and complex data validation purely through GraphQL mutations and queries, without needing a separate, imperative logic layer (like traditional Cloud Functions)?
2.2. Hypothesis
We hypothesize that by leveraging advanced GraphQL features and the underlying power of PostgreSQL (accessible via Data Connect), we can encapsulate most, if not all, of the core business logic directly within our Data Connect backend. This would create a more maintainable and "self-documenting" system where the API definition itself contains the business rules.
2.3. Experimental Work
(This section can be auto-populated by running make export-issues with the appropriate filters/labels.)
[Backend] Implement Full API Logic: This involves systematically testing the limits of Data Connect's mutation capabilities to handle transactional logic and data validation.[Web/Mobile] Full Application Re-wiring: This work will test the performance and ergonomics of the generated SDKs at scale, across dozens of components and screens.
2.4. Results & Learnings
(To be filled out upon milestone completion.)
Milestone 3: Production Readiness & Go-Live
3.1. Technological Uncertainty
The final uncertainty is whether our automated, monorepo-based deployment strategy is robust and reliable enough for production. Can we create CI/CD pipelines that can correctly build, test, and deploy three distinct artifacts (Web, Mobile, Backend) in a coordinated manner, while managing environment-specific configurations and secrets securely?
3.2. Hypothesis
We hypothesize that by using a combination of GitHub Actions for workflow orchestration and CodeMagic for specialized Flutter builds, managed by our central Makefile, we can create a fully automated "push-to-deploy" system for all environments.
3.3. Experimental Work
(This section can be auto-populated by running make export-issues with the appropriate filters/labels.)
[CI/CD] Configure Deployment Pipelines: This involves significant engineering work to script and test the automated build and deployment processes for each part of the monorepo.[Data] Create & Test Initial Data Import Scripts: Development of reliable and idempotent scripts to populate the production database.
3.4. Results & Learnings
(To be filled out upon milestone completion.)