Building the foodfusion Rails App — Ruby Deep Dive [24]
This is a detailed account of my journey creating foodfusion, an innovative food ordering platform. Over several days, I documented my progress, technical decisions, and the milestones achieved.
Links:
GitHub Repo: https://github.com/bhavyansh001/foodfusion
Live site: https://foodfusion.diversepixel.com/
Android app: https://github.com/bhavyansh001/foodfusion/raw/main/android-app/foodfusion.apk
Release notes: https://github.com/bhavyansh001/foodfusion/releases
Before we begin: Plan the Models
Initial Setup (Day 1)
I began by generating the Rails app with PostgreSQL and Tailwind for styling:
rails new foodfusion -d postgresql --css tailwind -T
Database Setup & Enum Usage for Devise User model
bundle add devise
rails g devise:install
rails db:create
Enums were introduced early to handle different user roles, like restaurant owners and visitors.
Why use enum:
1.
user = User.find(some_id)
user.owner! # This method is automatically created by the enum
2.
User.create(email: 'owner@example.com', password: 'password123', role: 'owner')
3.
def some_action
if current_user.owner?
# Owner-specific logic
elsif current_user.visitor?
# Visitor-specific logic
end
end
Then in our other models, we can do:
class Order < ApplicationRecord
belongs_to :visitor, class_name: 'User'
end
class Restaurant < ApplicationRecord
belongs_to :owner, class_name: 'User'
end
This allowed for clean role-specific logic throughout the app:
if current_user.owner?
# Owner-specific logic
elsif current_user.visitor?
# Visitor-specific logic
end
Developing Models (Day 2–4)
On Day 2, I created the initial models:
- Restaurant: Belongs to an owner.
- Menu & MenuItem: Associated with a restaurant, allowing CRUD operations on the menu.
Restaurant model migration update:
I modified migrations as needed, then committed changes to version control:
git checkout main
git pull
git checkout -b feature/add-restaurant
rails g model Restaurant name:string owner:references
# Similarly added more models:
rails g model Menu restaurant:references
rails g model MenuItem name:string price:decimal
availability:integer menu:references
MenuItem Model and migration update:
By Day 4, I had completed similar steps for Order and OrderItem models, enabling order status management.
This will help me do things like:
# Change the status of the order
order.confirmed! # Changes status to 'confirmed'
order.in_progress! # Changes status to 'in_progress'
# Check the current status
if order.completed?
puts "Order is completed!"
end
# List all orders with a specific status
completed_orders = Order.where(status: :completed)
Building the Controllers (Day 5–8)
During these days, I focused on setting up controllers for core functionalities.
- HomeController: The homepage features user authentication (login/sign-up), a list of all restaurants, and a search bar.
- RestaurantsController: Handles restaurant listing, menu display, and CRUD operations for owners.
- OrdersController: Manages order placement, confirmation, and real-time order status updates.
User Flow (Planning rest of the app)
The user flow was mapped out as follows:
- User comes to the website’s homepage, sees this:
- Login/SignUp button
- All Restaurants listed
- Search bar for restaurants - Clicks on a Restaurant
- Gets the Menu for that restaurant
- Can see the orderitems and modify quantity
- Places order - Redirected to Order confirmation page
- Order details
Moreover there will be:
- Dashboard for visitors
- Order history
- Active orders with status
- Account settings - Dashboard for restaurant owner
- Overview of active orders
- Order management system (accept, prepare, ready for delivery)
- Menu management (CRUD operations for menu items)
-Basic analytics (daily orders, popular items)
Additional Features & Integrations (Day 9–12)
Notifications & Background Jobs
By Day 12, I implemented a notification system using background jobs with SolidQueue. Email notifications are sent on order status updates.
Internationalization (I18n)
The platform supports both English and Hindi, providing a localized experience for users in different regions.
API Development (Day 13)
A RESTful API was introduced to allow external integrations. Key features include:
- Rate Limiting: To control traffic.
- Versioning: Ensures backward compatibility.
- Security Measures: Protects user data.
Front-end Enhancements (Day 14–15)
I integrated Hotwire (Turbo, Stimulus, Strada) to enhance the UI with real-time updates and a dynamic user experience.
The Turbo Native integration allows seamless mobile interactions via the Android app. Users can browse menus, place orders, and receive real-time status updates.
Testing & Deployment (Day 16–18)
Extensive tests were written for controllers and APIs, ensuring the app’s stability. The app was deployed on a VPS with SSL enabled at foodfusion.diversepixel.com.
The release of FoodFusion v1.0.0 included:
- Basic user and owner dashboards.
- Real-time order status updates.
- CRUD functionality for restaurant owners.
- A functional notification system using background jobs.
- Language support for English and Hindi.
Post-release Updates (Day 19)
Following the launch, FoodFusion v1.1.0 brought several UI updates, including improved dashboards and visual assets. Testing was expanded to cover newly added features, and a new logo was added for both the Android app and web platform.
Screenshots:
FoodFusion Release Notes:
Conclusion
This app was built to showcase my expertise with Rails and its libraries, emphasizing writing code with strong design principles and effective version control management.
By integrating modern features like real-time updates, internationalization, and a robust API, foodfusion demonstrates the power of well-architected Rails applications. Additionally, I implemented proper branching strategies, commit conventions, and managed structured releases, ensuring a scalable and maintainable development process. Stay tuned for future updates!