Name | |
---|---|
Andrew Nguyen | aynguyen@bu.edu |
Brennan Mahoney | bmm1@bu.edu |
Naomi Gonzalez | ngonzalz@bu.edu |
Hin Lui Shum | jshl@bu.edu |
Name | |
---|---|
James Colley | colleyloyejames@gmail.com |
Yashaswi Upmon | yashaswiupmon2407@gmail.com |
Supriya Nanjundaswamy | supriya.jog29@gmail.com |
- Download the APK: Google Drive Link
- Install on Device or Emulator:
- For physical devices: Transfer the APK file to your device and install it.
- For an emulator: Drag and drop the APK file into the running emulator.
- Run the Application.
- Wait at least 1 second on clicking "next" in onBoarding Screen or may cause crash
- Plaid link Page redirect to google.com, need manual alt tab return to app
- Plaid Link complete will remain on onBoarding screen for small delay
git clone https://github.com/EC528-Fall-2024/phone-pay-budget-tracker.git
cd Android/PhonePayBudgetTracker
npm install
cd android
touch local.properties
sdk.dir=/Users/<your-username>/Library/Android/sdk
./gradlew --refresh-dependencies
cd ..
npm install -g expo-cli
npx expo install nativewind tailwindcss react-native-reanimated react-native-safe-area-context
open -a "/Applications/Android Studio.app" ./android
npx expo run:android
- XCode
- IOS Xcode Simulator
git clone https://github.com/EC528-Fall-2024/phone-pay-budget-tracker.git
cd IOS/Frontend
npm install
npx expo start
cd admin_portal
npm install
npm start
The goal of the project is to create a scalable, cloud-native, budget-tracking mobile app that integrates with plaid for an all-in-one space to view and analyze your financial data.
This app will be used by anyone who wants to improve their financial literacy, has trouble tracking their expenses, needs easy visuals to improve their spending habits, or just has too many bank accounts/credit cards to manage individually.
-
John
- Description: John has multiple checking accounts, credit cards, and saving accounts. He sometimes does not remember to check all his accounts and does not have the time to adequately control all his spendings from these various sources.
- Needs: John needs one app to track his payments throughout his 15 different cards and accounts without having to check the app of each individual bank.
-
Admin
- Description: Admin is responsible for managing user access and maintaining the integrity of the app. They ensure that all users comply with the law and the rules of the app, preventing fraudulent activities, and maintaining smooth operation for all users
- Needs: Admin needs a centralized control panel to restrict access for select users. This page should only be accessible to those of Admin level through secure login. They should also be able to view and delete users.
In Scope:
- Secure user registration and authentication
- Admin management page with user viewing and deleting capabilities
- Track transaction history from bank accounts
- Intuitive expense analysis and visualizations
- Unit tests and cloud deployment
- Scalable database for secure app data
- Connect and scale app using cloud provider
Out of Scope:
- Fully launched app
Plaid is used as a reputable and safe third party api to link user bank account information. It is used to pull transaction data from linked accounts.
- Frontend: React Native + Expo
- Authentication: AWS Cognito
- Controls user sign up and login as well as token validation in microservices
- Microservices using AWS lambda functions
- Transaction and Data Analysis:
- AWS CloudFormation: template to define infrastructure of microservice
- Plaid API: access financial information
- Node.js
- REST API’s
- User Profile:
- AWS CloudFormation: template to define infrastructure of microservice
- Node.js
- REST API’s
- Admin Control:
- React web app: frontend for admin portal
- AWS Cognito role-based access control
- REST APIs
- Python
- Transaction and Data Analysis:
- API Gateway: AWS API Gateway
- CI/CD: GitHub Actions
- Database: DynamoDB
- Frontend: React Native + Expo
- Authentication: Firebase Auth
- Account & Transaction Data: Plaid API
- Database: Cloud Firestore
- Admin Control: React App + DynamoDB + AWS Cognito + Firebase Auth
- API Gateway: GCP Cloud Functions
- CI/CD: GitHub Actions
Here is an overview of the project structure:
PhonePayBudgetTracker/
├── functions/
└── index.js # Cloud functions integration
└── app/
└── (auth)/
├── _layout.tsx # Layout for authentication-related screens
├── loginScreen.tsx # User login screen
└── signupScreen.tsx # User signup screen
└── (components)/
├── AccountCard.js # Displays account details
├── DonutChart.tsx # Visualizes spending by category as a donut chart
├── inputForm.tsx # Reusable input form component
├── LineChart.tsx # Displays monthly spending trends as a line chart
├── TopCategoriesCard.tsx # Shows top spending categories
├── TopTransactionsCard.tsx # Shows top transactions by spending
└── TransactionCard.js # Displays individual transaction details
└── (context)/
├── accountContext.tsx # Context for managing account data
├── transactionContext.tsx # Context for managing transaction data
└── UserContext.tsx # Context for managing user information
└── (sections)/
├── Accounts.js # Displays accounts overview on dashboard
├── Header.js # Header component with navigation toggle
├── Sidebar.js # Sidebar navigation menu
└── Transaction.js # Displays transaction list on dashboard
└── (tabs)/
├── _layout.tsx # Layout for post-login navigation
├── aboutUsScreen.tsx # About Us screen with app details
├── analysisScreen.tsx # Spending analysis and trends
├── billPlanScreen.tsx # Billing plan selection screen
├── helpCenterScreen.tsx # Help center screen with FAQs
├── mainScreen.tsx # Main dashboard after login
├── manageScreen.tsx # Edit user profile and settings
├── onBoardingScreen.tsx # New users onboarding and link Plaid
├── privacyPolicyScreen.tsx # Privacy policy details
└── profileScreen.tsx # Application settings and details
└── (utils)/
├── fetchUtils.tsx # Utility functions for data fetching
├── linkPlaidUtils.tsx # Utility functions for Plaid integration
├── loginUtils.tsx # Helper functions for login
├── signupUtils.tsx # Helper functions for signup
└── validationUtils.jsx # Validation for login/signup form inputs
└── _layout.jsx # Main layout entry point for the app
Design Implications and Discussion:
This application adopts a microservice architecture to enable modular development, scalability, and flexibility in technology choices for each service. Here is an overview of the key components:
Architecture Components:
- Front-end GUI/UI
- Purpose: We aim to provide users with an intuitive and visually appealing interface for viewing their consolidation financial data. Graphs and visualizations make sure data is easy to digest and understand.
- Why: Ensures smooth user experience and simplifies data.
- API Functions Entry Points
- Purpose: Each microservice exposes unique API endpoints to enable interactions with specific functions. AWS / GCP serverless architecture supports real-time scalability by adjusting resources based on request volumes
- Why: AWS API Gateway / GCP Cloud Functions ensures the modularity of our microservices, scalability, and efficient deployment
-
Authentication
- Purpose: AWS Cognito / Firebase Auth manages user authentication and role-based access control. All users are added to a shared user pool, with admins added to a group within the pool with elevated privileges. Tokens from Cognito secure access to the API Gateway and the Lambda functions to keep all data secure.
- Why: For a financial application, security is paramount. Cognito provides a robust and centralized approach to managing security concerns within the app.
-
Transaction and Data Analysis
- Purpose: Plaid securely links and aggregates users’ bank account data. This service collects, organizes, and analyzes pulled users' transaction data from various different payment platforms, and bank accounts.
- Why: Have an independent and secure service to handle user financial information.
-
Security Implementations
-
Purpose: Our application ensures the security and privacy of user data through strict measures, including never returning sensitive information like the accessToken to the client side and leveraging encrypted identifiers for database keys. These measures safeguard user data from potential breaches or misuse.
-
Implementation:
- Access Token Protection: The accessToken is securely stored server-side and is never exposed to the client. All operations requiring the accessToken (e.g., retrieving transactions or account balances) are handled via server-side APIs. This minimizes the risk of unauthorized access.
- Encrypted UID for Database Keys: User database entries utilize an encrypted version of the user's UID as their identifier. This obfuscation prevents direct access to user data and ensures that even in the unlikely event of a breach, the database structure and keys remain incomprehensible to malicious actors.
-
Why: These security measures are essential for a financial application handling sensitive user data. By never exposing critical information like accessToken to the client and using encrypted UIDs as keys, we create a layered security approach that protects user privacy and ensures data integrity across the application.
-
-
Data Storage Design: Platform-Specific Approach
- Purpose:
To provide an optimized user experience tailored to platform-specific needs, the design of transaction data storage varies between iOS and Android platforms:
- iOS: Transaction data is stored in a secure centralized database to ensure persistent access across sessions and devices.
- Android: Transaction data is stored locally in React Context (local cache) to prioritize performance and responsiveness during active sessions.
- Implementation:
- iOS Database Storage: Transaction data is securely stored in a backend database. This design ensures data is available across multiple devices and persists beyond app closures or reinstallations. The centralized storage also enables server-side analytics and efficient backup solutions.
- Android Local Cache: Transaction data is stored locally in memory using React Context. This lightweight solution focuses on fast, session-specific access, allowing the app to fetch and update data dynamically without frequent server calls. The local cache is reset upon logout or session expiration for security and consistency.
- Why:
- iOS (Database):
- Ensures long-term persistence of user data across sessions and devices.
- Supports centralized analytics and backup mechanisms.
- Offers consistency for iOS users who frequently access data on multiple Apple devices.
- Android (Local Cache):
- Provides a performance-centric design, minimizing server dependencies for real-time data retrieval during active use.
- Enhances app responsiveness by avoiding network latency for every transaction update.
- Simplifies development for session-specific data management, aligning with Android's diverse device ecosystem.
- iOS (Database):
- Purpose:
To provide an optimized user experience tailored to platform-specific needs, the design of transaction data storage varies between iOS and Android platforms:
-
User Profile
- Purpose: Holds user metadata and unique settings for their profile.
- Why: A user must be able to tailor an app experience to their needs and store information on the number of accounts linked.
- Admin Control
- Purpose: A totally separate interface from the financial app for security. Admins are able to see users of the app and remove them if they feel as if the user is using the application for malicious purposes.
- Why: Ensures proper oversight and management of the platform without giving too much access.
- Integration Layer
- Purpose: Ensures consistent and reliable performance of the application through unit test coverage of both the frontend and backend components. A CI/CD pipeline automates testing and cloud deployment.
- Why: Promotes software consistency and quality and a streamlined development and update process.
Minimum Acceptance Criteria:
- App able to run on IOS and Android emulators
- Able to securely receive financial information
- Able to create simple analyses and graphs from data received
- Able to manage data and see its overview from the admin portal
- Sprint 1 | Video | Slides
- Make design decisions and create plan for development
- Create simple test UI of app pages using React Native
- Create and test local API gateway
- Sprint 2 | Video | Slides
- Analyze architecture decisions and make adjustments
- Add authentication using AWS Cognito and implement sign up and login
- Create bases for all microservices
- Start CI/CD pipeline to ensure smooth further development
- Connect microservice to API gateway and test locally
- Sprint 3 | Video | Slides
- Choose Plaid third-party API and connect to transaction and data analysis microservice.
- Successfully store mock data in DynamoDB and display in IOS Expo app
- Update UI
- Separate IOS and Android for ease of development
- Sprint 4 | Video | Slides
- Create real Plaid user and connect to app
- Update microservices to correctly connect databases, API gateway, and frontend
- More UI updates
- end-to-end IOS integration
- Sprint 5 | iOS -> Video | Slides
| Android -> Video | Slides
- Increase security of app by managing Cognito tokens throughout API gateway and microservices
- Secure database by only allowing certain actions to certain functions
- Admin portal able to view and delete users
- Have unit tests for everything
- Deploy microservices and API gateway to cloud
- Deployment discussions and considerations for scalability
- Final Presentation | Video | Slides