mirror of
https://github.com/dat515-2025/Group-8.git
synced 2026-03-22 06:57:47 +01:00
update checklist
This commit is contained in:
@@ -8,54 +8,54 @@ The core deliverables are required.
|
||||
This means that you must get at least 2 points for each item in this category.
|
||||
|
||||
| **Category** | **Item** | **Max Points** | **Points** | **Comment** |
|
||||
|:---------------------------------|:----------------------------------------|:---------------|:-----------|:----------------------------------------------------------------------------------------------------|
|
||||
|:---------------------------------|:----------------------------------------|:---------------|:-----------|:-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|
|
||||
| **Core Deliverables (Required)** | | | | |
|
||||
| Codebase & Organization | Well-organized project structure | 5 | 5 | Project is well-organized |
|
||||
| Codebase & Organization | Well-organized project structure | 5 | 5 | Project is well-organized, each part is separated (backend, frontend, IaC) and these parts are separated even mode (modules, packages...) |
|
||||
| | Clean, readable code | 5 | 4 | Should be readable(function names should help), but readability can always be improved |
|
||||
| | Use planning tool (e.g., GitHub issues) | 5 | 4 | We used Github issues |
|
||||
| | Proper version control usage | 5 | 5 | We used branches for development, pull request reviews |
|
||||
| 23 | Complete source code | 5 | 5 | The code is complete |
|
||||
| Documentation | Comprehensive reproducibility report | 10 | 8 | Our report is precise |
|
||||
| 23 | Complete source code | 5 | 5 | The code is complete - entire codebase is in this repository |
|
||||
| Documentation | Comprehensive reproducibility report | 10 | 10 | Our report is precise, anybody should be able to reproduce our deployment by following provided instructions |
|
||||
| | Updated design document | 5 | 4 | Our design document was updated and merged into the report |
|
||||
| | Clear build/deployment instructions | 5 | 5 | Should be clear |
|
||||
| | Troubleshooting guide | 5 | 3 | When it comes to troubleshooting, there is never enough documentation |
|
||||
| | Completed self-assessment table | 5 | 5 | Completed. |
|
||||
| 30 | Hour sheets for all members | 5 | 5 | Filled. |
|
||||
| Presentation Video | Project demonstration | 5 | 5 | Yes |
|
||||
| | Code walk-through | 5 | 3 | There was not enough time to go through all of our code |
|
||||
| | Code walk-through | 5 | 3 | There was not enough time to go through all of our code, so we just mentioned some parts of it. |
|
||||
| 13 | Deployment showcase | 5 | 5 | Yes |
|
||||
| **Technical Implementation** | | | | |
|
||||
| Application Functionality | Basic functionality works | 10 | 10 | The app works as intended |
|
||||
| | Advanced features implemented | 10 | 5 | OAuth, BankAPI connection (not only mock bank) |
|
||||
| | Error handling & robustness | 10 | 5 | The app should be robust enough for normal use (TODO Lukasi kdyztak oprav pls) |
|
||||
| 24 | User-friendly interface | 5 | 4 | Could always be better |
|
||||
| Backend & Architecture | Stateless web server | 5 | 0 | Our server is stateful |
|
||||
| | Stateful application | 10 | 10 | Our server is stateful |
|
||||
| | Database integration | 10 | 10 | Yes, db is integrated |
|
||||
| | Error handling & robustness | 10 | 5 | App notifies user about errors, errors in code are also logged by sentry and we get notified |
|
||||
| 24 | User-friendly interface | 5 | 4 | Responsive interface with dark mode support, should by user friendly enough |
|
||||
| Backend & Architecture | Stateless web server | 5 | 0 | Our server is stateful TODO: v tomhle mám furt bordel |
|
||||
| | Stateful application | 10 | 10 | Our server is stateful TODO: v tomhle mám furt bordel |
|
||||
| | Database integration | 10 | 10 | We have deployed 3 MariaDB nodes with replication, MaxScale proxy and periodic backups. Connection app with this setup is same as with standalone db. |
|
||||
| | API design | 5 | 5 | Backend APIs are implemented with public Swagger docs |
|
||||
| 28 | Microservices architecture | 10 | 3 | Well not really but we have the app and the worker services divided (TODO Lukasi kdyztak oprav pls) |
|
||||
| Cloud Integration | Basic cloud deployment | 10 | 10 | Yes (In private cluster) |
|
||||
| | Cloud APIs usage | 10 | 0 | Not Applicable (TODO Lukasi kdyztak oprav pls) |
|
||||
| | Serverless components | 10 | 0 | No (TODO Lukasi kdyztak oprav pls) |
|
||||
| 10 | Advanced cloud services | 5 | 0 | Not Applicable (TODO Lukasi kdyztak oprav pls) |
|
||||
| 28 | Microservices architecture | 10 | 3 | We have separated API deployment and worker deployment. Worker process slow tasks - emails, payment scraping. There is no need for another service in current state but adding it is easy. |
|
||||
| Cloud Integration | Basic cloud deployment | 10 | 10 | Yes (In private cluster), using GH Actions and self-hosted runner. |
|
||||
| | Cloud APIs usage | 10 | 8 | GH Actions deploys frontend to Cloudflare Pages, deployment creates CF tunnel record automatically |
|
||||
| | Serverless components | 10 | 10 | We are using CF pages for frontend deployment |
|
||||
| 10 | Advanced cloud services | 5 | 5 | Using CF provides us with DDOS protection, access rules, it hides our IP |
|
||||
| **DevOps & Deployment** | | | | |
|
||||
| Containerization | Basic Dockerfile | 5 | 5 | Yes |
|
||||
| | Optimized Dockerfile | 5 | 0 | Not really (TODO Lukasi kdyztak oprav pls) |
|
||||
| | Docker Compose | 5 | 5 | dev only |
|
||||
| 15 | Persistent storage | 5 | 5 | Yes |
|
||||
| Deployment & Scaling | Manual deployment | 5 | 5 | Yes, possible |
|
||||
| | Automated deployment | 5 | 5 | Yes, withGithub runners |
|
||||
| | Multiple replicas | 5 | 5 | Yes (4) |
|
||||
| | Optimized Dockerfile | 5 | 5 | Rootless Dockerfile |
|
||||
| | Docker Compose | 5 | 5 | For development environment |
|
||||
| 15 | Persistent storage | 5 | 5 | Yes, using Longhorn. |
|
||||
| Deployment & Scaling | Manual deployment | 5 | 5 | Yes, possible by using Helm manually |
|
||||
| | Automated deployment | 5 | 5 | Yes, with Github actions |
|
||||
| | Multiple replicas | 5 | 5 | Yes, 3 pods with API, 3 pods with workers, 3 database pods |
|
||||
| 25 | Kubernetes deployment | 10 | 10 | Yes |
|
||||
| **Quality Assurance** | | | | |
|
||||
| Testing | Unit tests | 5 | 2 | Basic coverage |
|
||||
| Testing | Unit tests | 5 | 4 | All workflows is covered by tests |
|
||||
| | Integration tests | 5 | 5 | Yes |
|
||||
| | End-to-end tests | 5 | 5 | Yes |
|
||||
| 12 | Performance testing | 5 | 0 | No |
|
||||
| Monitoring & Operations | Health checks | 5 | 5 | Yes |
|
||||
| | Logging | 5 | 2 | only to terminal add logstash |
|
||||
| | Metrics/Monitoring | 2 | 2 | Yes |
|
||||
| 12 | Custom Metrics for your project | 3 | 3 | Prometheus, Grafana |
|
||||
| | Logging | 5 | 2 | Logs can be accessed easily using Grafana |
|
||||
| | Metrics/Monitoring | 2 | 2 | Yes, visualised in Grafana |
|
||||
| 12 | Custom Metrics for your project | 3 | 3 | Yes, API has /metrics endpoint providing information about FastAPI itself and custom information such as number of users or transactions. |
|
||||
| Security | HTTPS/TLS | 5 | 5 | Yes |
|
||||
| | Authentication | 5 | 5 | Yes |
|
||||
| 15 | Authorization | 5 | 5 | Yes |
|
||||
@@ -63,9 +63,10 @@ This means that you must get at least 2 points for each item in this category.
|
||||
| Advanced Features and | AI/ML Integration | 10 | 0 | No |
|
||||
| Technical Excellence | Real-time features | 10 | 0 | No |
|
||||
| | Creative problem solving | 10 | 4 | Cron jobs for bank scraping |
|
||||
| | Performance optimization | 5 | 3 | Delegating emails and scraping to workers |
|
||||
| 7 | Exceptional user experience | 5 | 0 | |
|
||||
| | Performance optimization | 5 | 4 | Delegating emails and scraping to workers, hosting frontend on CF |
|
||||
| 7 | Exceptional user experience | 5 | 3 | |
|
||||
| **Total** | | **255** | **214** | |
|
||||
|
||||
## Grading Scale
|
||||
|
||||
- **Minimum Required: 100 points**
|
||||
|
||||
@@ -47,6 +47,7 @@ flowchart TB
|
||||
svc <-- HTTP request/response --> api[("UniRate API")]
|
||||
client <-- HTTP request/response --> n2
|
||||
```
|
||||
|
||||
The workflow works in the following way:
|
||||
|
||||
- Client connects to the frontend. After login, frontend automatically fetches the stored transactions from
|
||||
|
||||
Reference in New Issue
Block a user