Complex Prompt to Test a Coding Model: "Micro-SaaS Analytics Dashboard"
You are tasked with developing a full-stack application that serves as an analytics dashboard for a fictional "Micro-SaaS" platform. The application should handle user authentication, data ingestion from various sources, real-time data processing, and dynamic visualization of key metrics. Focus on robust error handling, scalability considerations, and secure API design.

Here are the specific requirements:

Part 1: Backend Development (Python/FastAPI)
User Management & Authentication:

Implement a secure user registration and login system using JWT (JSON Web Tokens) for authentication. Store user data (username, hashed password, email) in a PostgreSQL database.
Include password reset functionality (simulated via console output or a mock email service).
Implement role-based access control (RBAC): admin and user roles. Admins can view all data; users can only view data related to their own SaaS applications.
Data Ingestion & Storage:

Design a RESTful API endpoint (/api/v1/data/ingest) that accepts JSON payloads representing event data from different "Micro-SaaS" applications. Each payload should include:
app_id (UUID, identifies the SaaS application)
event_type (e.g., page_view, signup, purchase, api_call)
user_id (UUID, internal user ID within the SaaS app)
timestamp (ISO 8601 format)
metadata (JSONB, flexible key-value pairs for additional event details)
Store this raw event data in a PostgreSQL database. Optimize table schema for efficient querying of time-series data (e.g., partitioning or indexing strategies).
Implement data validation for incoming payloads, returning appropriate HTTP status codes (e.g., 400 Bad Request) for invalid data.
Real-time Processing & Aggregation (Simulated):

Create a background task/worker (e.g., using Celery or a simple in-memory queue) that processes ingested events.
For each ingested event, update pre-calculated aggregate metrics stored in a separate PostgreSQL table. Metrics to track:
Daily Active Users (DAU) per app_id
Monthly Recurring Revenue (MRR) per app_id (based on purchase events with a revenue field in metadata)
API Call Count per app_id and endpoint (from api_call events with an endpoint field in metadata)
Conversion Rate (e.g., signup events divided by page_view events) per app_id
The aggregation logic should be idempotent to handle retries.
Analytics API Endpoints:

Expose endpoints for retrieving the aggregated metrics:
/api/v1/analytics/dau?app_id={uuid}&start_date={date}&end_date={date}
/api/v1/analytics/mrr?app_id={uuid}&start_date={date}&end_date={date}
/api/v1/analytics/api_calls?app_id={uuid}&start_date={date}&end_date={date}
/api/v1/analytics/conversion_rate?app_id={uuid}&start_date={date}&end_date={date}
Ensure proper authorization: a user can only query for app_ids they own or if they have an admin role.
Implement pagination and filtering for results.
Error Handling & Logging:

Implement comprehensive error handling with custom exception classes and appropriate HTTP responses.
Integrate a logging library (e.g., logging) to log application events, errors, and warnings to the console and a file.
Part 2: Frontend Development (React/Next.js)
User Interface:

Develop a responsive single-page application (SPA) that interacts with the backend APIs.
Login and Registration pages.
A dashboard view that displays the aggregated metrics using interactive charts (e.g., line charts for time-series data, bar charts).
Allow users to select an app_id (if they have multiple) and a date range for filtering the displayed data.
Display a table or list of recent raw events ingested for the selected app_id.
Data Visualization:

Utilize a charting library (e.g., Recharts, Chart.js, Nivo) to visualize the DAU, MRR, API Calls, and Conversion Rate.
Charts should be dynamic and update based on user selections.
Authentication & State Management:

Persist user authentication state (JWT) in localStorage or sessionStorage.
Implement protected routes that require authentication.
Manage application state (user data, selected app_id, fetched analytics data) using a state management library (e.g., Redux, Zustand, React Context API).
Error Handling & User Feedback:

Display user-friendly error messages for API failures.
Show loading indicators while fetching data.
Part 3: Deployment & Infrastructure (Conceptual/Setup Instructions)
Dockerization:

Provide Dockerfiles for both the backend and frontend services.
Provide a docker-compose.yml file to orchestrate the application (backend, frontend, PostgreSQL database).
Scalability & Security Considerations (Discussion/Best Practices):

Discuss how you would scale the application (e.g., message queues for event processing, read replicas for the database, load balancing).
Outline security best practices beyond JWT (e.g., input sanitization, rate limiting, secure environment variables, HTTPS).
Deliverables:
Complete source code for both backend and frontend.
Clear setup instructions for running the application locally using Docker Compose.
A README.md file that:
Explains the project structure.
Details the API endpoints and their usage.
Outlines the design decisions and trade-offs made.
Discusses the scalability and security considerations mentioned in Part 3.
Screenshots/GIFs of the working frontend dashboard.
Evaluation Criteria:
Correctness and Completeness: Does the application meet all specified requirements?
Code Quality: Is the code clean, well-structured, maintainable, and properly commented? Are best practices followed (e.g., DRY, SOLID principles)?
Error Handling and Robustness: How well does the application handle various error scenarios?
Security: Are common security vulnerabilities addressed?
Performance (conceptual): Are performance considerations evident in the design (e.g., database indexing, efficient querying)?
Documentation: Is the README.md comprehensive and easy to understand?
Dockerization: Are the Dockerfiles and docker-compose.yml functional and well-configured?