Docker Volume & Seeding: Image Persistence & Data Population

by Admin 61 views
Docker Volume & Seeding: Image Persistence & Data Population

Hey guys! This is all about making sure our images stick around even when our Docker containers reboot and making it easier to get some sample data in there. We're talking about setting up Docker Volumes for persistent image storage and seeding our database with some cool sample images. Let's dive in!

📝 Project Overview: Fixing Image Loss and Implementing Seeding

Currently, every time we restart our Docker container, we lose all the images that users upload. This is because they're saved in the container's temporary file system. Also, the initial data population script (data.sql) adds products to the database, but the actual image files aren't there, leading to 404 errors and broken images on the frontend. This project tackles these issues head-on. The goal is to set up persistent file storage using Docker Volumes, revamp the backend to store only file names (making it more flexible), and create a mechanism to automatically populate our system with real images for demo purposes. This ensures our application is more robust and provides a better user experience by handling image persistence and data seeding effectively. We are going to ensure that the images uploaded are preserved in the system, even when the container restarts. This is super important to ensure that all the products and other important things we will display on the frontend look and work as expected.

Why This Matters

  • Data Persistence: Prevents loss of user-uploaded images.
  • Improved User Experience: Ensures images load correctly on the frontend.
  • Simplified Development: Makes it easier to set up a working environment with sample data.
  • Enhanced Reliability: The system won't crash when an image cannot be found.

🚀 Goals and Tasks: Docker, Backend, and Data

This project is broken down into a few key areas: infrastructure (Docker), backend refactoring, and data seeding. It's a comprehensive approach to making sure our images are safe and our system is ready to go. The objectives are quite ambitious, but well-structured, targeting various aspects of the application to ensure that the image handling and data population processes are as efficient and reliable as possible. We'll be configuring Docker, tweaking the backend code, and writing scripts to populate our system with data. This involves setting up Docker Volumes to ensure data persistence, refactoring the backend to handle image file names, and creating a seeding mechanism to populate images automatically. Let's break it down:

1. Infrastructure (Docker): Setting Up the Foundation

  • Docker Configuration: We'll be configuring Docker using bind mount in the compose.yml file. This maps the local ./images directory on the host machine to the /app/images directory inside the container. This is how we ensure that our images are stored on the host, making them persistent even when the container restarts. Docker will handle all the heavy lifting and make sure that the mapping is set up correctly.

    • [ ] Configure bind mount in compose.yml mapping ./images (host) to /app/images (container).

  • Automatic Subfolder Creation: We need to make sure that the necessary subfolders (like products, restaurantAboutUs, etc.) are created automatically when the application starts. This ensures that the file structure is ready to go and that there are no errors related to the image storage system.

    • [ ] Ensure subfolders (products, restaurantAboutUs, etc.) are created automatically upon application startup.

2. Backend (Refactoring): Adapting the Code

  • Entity Modifications: We'll change the Product and Restaurant entities to store image file names as strings instead of full URLs. This makes our system more flexible and easier to manage, because we won't have to worry about complex URL structures. Instead, we're going to keep the image file name in the database. This is a crucial step in the decoupling process, ensuring that the backend can handle images more efficiently and robustly.

    • [ ] Change entities (Product, Restaurant) to save images as String (file name) instead of full URI.

  • Mapper Updates: We'll update the Mappers to dynamically reconstruct the full URL in the API responses. This means the frontend will still get the full URL to display the image, but the backend will store only the file name. The mappers will be updated to reconstruct the full image URL dynamically when providing API responses. This ensures that the frontend receives the necessary information to display images correctly.

    • [ ] Update Mappers to reconstruct the full URL dynamically in the API response.

  • Filename Sanitization: To prevent issues, like special characters and duplicates, we'll implement a sanitizeFilename function in the RestaurantService. This is important because it prevents issues with special characters and duplicate file names, making the system more robust.

    • [ ] Implement sanitizeFilename in RestaurantService to avoid special characters and duplicates.

  • Safe Deletion: We'll implement