Development of a Meat image and Taste Data Collection and Storage System

1. Project Overview

Project Background

• Deep Plant and SKKU Industry-Academic Collaboration Project
• Systematically collect customer/buyer taste preferences for meat based on meat images and analyzed taste data, and based on this, the goal is to build an AI prediction model that automatically classifies and predicts detailed taste data for meat based on images, and to develop a system for optimized personalized meat recommendations for future customers/buyers.

Project Title

• Development of a meat image and taste data collection and storage system

Development Details

1. Backend Cloud Server
   • Implementation of a cloud server using AWS and database design
2. Mobile Application
   • Collection of meat information, local temporary storage, and data modification
3. Admin Web
   • Storage and management of collected meat information, data statistical analysis processing, and implementation of meat information prediction through images.

2. Demo Link

App

Web

3. Production Duration & Participants

Production Duration

• 2023.05 ~ 2023.12

Backend Engineer

정성훈 (Seonghun Jung)
GitHub: @SincerityHun
SKKU CS Junior

Mobile Application Engineer

전수현 (Suhyeon Jeon)	송의영 (Euiyeong Song)
GitHub: @junsu0573	GitHub: @hosicuro
SKKU CS Sophomore	SKKU CS Sophomore

Web Application Engineer

김성중 (Seongjung Kim)	박수현 (Suhyun)
GitHub: @qpwozxc	GitHub: @claspsh
SKKU CS Sophomore	SKKU CS Junior

4. Tech Skills

• Since this is a personal blog, I will only disclose the technology stack I utilized, not the details of the entire project.

Environment

• 

Release

• 

Development

• 

Communication

• 

5. Service Flow & Core Features with Architecture

• System Configuration and User Roles.
  1. Normal
  2. Researcher
  3. Manager
• “Normal” User (part-time employees, outsourcing companies)
  • Generation of data through cross-sectional analysis of freshly slaughtered meat and entry of meat information.
  • Ability to modify own data within three days.
  • Access to review only self-created data.
• “Researcher” User (lab researchers, head office employees)
  • Capability to generate new data from both fresh and processed meat.
  • Authorization to approve data created by “Normal” users if no abnormalities are detected.
  • “Permission” to modify approved data and add supplementary information.
  • Access to view all system data.
• “Manager” User (administrator)
  • Elevated privileges as a Super User.
  • Responsibilities include user permission modification and information management.
• Service flow
  • Upon entry of basic fresh meat information by a “Normal” user, the “Researcher” user can perform the following functions:
    1. Input of additional experimental data derived from processing the relevant fresh meat, including:
       • Utilization of QR code or barcode recognition.
       • Implementation of Excel import/export capabilities.
       • Execution of specific data rejection and approval processes.
       • Application of data restoration using the Recycle Bin.
    2. Compilation and analysis of overall statistical data, including:
       • Regional trends in fresh meat slaughter.
       • Variations in quality grades based on processing status.
       • Alterations in taste profiles relative to processing frequencies.
       • Other related metrics.
    3. Prediction of meat grade and taste profiles using cross-sectional data analysis.
• System Architecture Overview
  
  • Flutter App, React Web
    • Interfaces utilized by Normal and Researcher users, respectively.
    • Collection of basic data and imagery of fresh meat via Flutter App.
    • Entry and management of additional processed meat data, alongside statistical analysis and prediction capabilities, through React Web.
  • Firebase Storage
    • Acts as an intermediary storage for images of fresh and processed meat.
    • Provides a buffer to manage simultaneous modifications of identical images from the app and web before final database entry (S3 storage).
  • RDS Postgresql DB, S3 Storage
    • RDS PostgreSQL DB stores basic meat data, sensory test results, and laboratory data.
    • S3 Storage houses cross-sectional imagery of fresh, heated, and processed meats.
  • Elastic Load Balancer
    • Distributes network load across three EC2 instances.
  • AWS EC2 Instance
    1. NGINX
       • Functions as a Reverse Proxy Server for Load Balancing and Enhanced Security.
    2. Gunicorn
       • Serves as a Web Server Gateway Interface for efficient traffic management.
    3. Flask Server(Single Process)
       • Modularization
         • Emphasizes modular design, separating DB Schema and DB Controller.
       • API Segregation
         • Implements API Segregation through a structured Request and Response Model.

6. Database Entity-Relationship Diagram (ERD)

• For the implementation of our service, the Database ERD is structured as follows:

7. Trouble Shooting

1. Database Architecture Design:
   • What are the best practices for implementing a robust and efficient database architecture?
2. API Specification Development:
   • How can we develop an API specification that is both scalable and maintainable, ensuring long-term service reliability?
3. Concurrent Database Access Management:
   • What strategies can be employed to effectively manage issues arising from simultaneous database access by multiple users?
4. Traffic Scalability Solutions:
   • What architectural improvements are necessary to accommodate and efficiently handle increasing levels of traffic?
5. Continuous Deployment Processes:
   • How can we implement a seamless, non-stop deployment cycle utilizing Continuous Integration/Continuous Deployment (CI/CD) workflows, specifically through the integration of Docker and GitHub?

8. Retrospective