FOOD X MARKET

FOOD X MARKET

Para Upendar , Kotha Soumith Reddy , Durgam Prasad , Kothuri Ganesh, M Shravan

Computer Science Engineering, Keshav Memorial Institute of Technology/JNTUH, Narayanguda,Hyderabad.

Abstract:. This paper presents FoodXMarket, a full-stack mobile application that connects users with on-demand home services such as plumbing and electrical work. The frontend is built using Flutter (Dart) with Provider for state management, while the backend utilizes Node.js with Express.js to handle RESTful API communication. Firebase Firestore enables real-time data updates for order tracking and worker assignment, and Firebase Authentication ensures secure user management. An AI-powered chatbot integrated via Dialogflow interprets user queries and maps them to relevant services, enhancing the overall user experience. The application supports cart management, payment flow, and dynamic worker assignment based on availability, making it a scalable and intelligent platform for modern service delivery.

Indexterms:Flutter, Firebase Firestore, Firebase Authentication, Node.js, Express.js, Dialogflow, REST API, Provider State Management, AI Chatbot, On-Demand Services. .

1. INTRODUCTION

   ‌We live in a time where almost everything is just a tap away, yet finding a reliable plumber or electrician at the right moment still feels surprisingly difficult. Most people either rely on word of mouth or spend hours searching online, with no guarantee of quality, availability, or fair pricing. This everyday frustration is what inspired the development of FoodXMarket, a mobile application designed to make home service booking as simple and straightforward as possible.

   FoodXMarket was built with the end user in mind. The application brings together a clean, easy-to-navigate interface developed in Flutter and Dart,

   allowing users to browse services, place orders, and track their requests without any confusion. Behind the

   scenes, a Node.js and Express.js backend quietly handles all the heavy lifting, managing API calls and keeping everything running smoothly between the

   need, and the chatbot figures out the right service for them. It feels less like using an app and more like talking to someone who actually understands whatyou are looking for. Together, these features create a platform that is not just functional, but genuinely useful in everyday life.

   The rest ofthis paper is organized as follows. Section

   II discusses the system architecture and module evaluation. Section III details the chatbot logic and Dialogflow integration. Section IV explains the worker assignment system. Section V presents the performance evaluation, followed by the conclusion and references.

2. SYSTEM ARCHITECTURE AND MODULE EVALUATION

   ‌The architecture of FoodXMarket is designed to be modular, scalable, and maintainable. The system is divided into three primary layers: the presentation

   app and the server.One of the more interesting layer (Flutter frontend), the business logic layer

   aspects of the project is how it handles real-time updates. Using Firebase Firestore, the app reflects live changes instantly, whether that is a worker being assigned, an order status changing, or a new request coming in. Login and user management are handled

   securely through Firebase Authentication, ensuring that both customers and workers have a safe

   experience on the platform.What makes FoodXMarket stand out is its built-in AI chatbot

   (Node.js backend), and the data layer (Firebase

   Firestore). Each layer communicates through well-defined interfaces, ensuring that changes in one layer do not break the others.

   The Flutter frontend is structured around a widget tree with Provider managing state across the application. Each screen, whether it is the home page,

   service listing, cart, or order history, subscribes to specific state notifiers. This means that when data

   powered by Dialogflow. Rather than making users changes, only the affected parts of the UI rebuild,

   dig through menus, they can simply type what they

   keeping the application fast and efficient even as

   complexity grows.The Node.js and Express.js backend serves as the intermediary between the frontend and external services. It exposes a set of RESTful API endpoints that handle chatbot communication, payment processing initiation, and service routing. All API calls are authenticated using Firebase tokens, ensuring that only valid users can trigger backend operations.Firebase Firestore acts as the live backbone of the application. Its real-time streaming capability means that when a worker is assigned to a job or when an order status changes, every connected client receives that update within milliseconds without needing to poll the server. This is especially important for the order tracking feature, where users expect to see changes immediately.

   The table below summarizes each core module along with its estimated response time and resource load, similar in spirit to how hardware blocks are evaluated in digital design for delay and area.

   Module	Technology Used
   AI Chatbot	Dialogflow+Express.js
   User Authentication	Firebase Auth
   Real-Time DB Read	Firestore Streams
   REST API Call	Node.js + Express
   UI State Update	Provider (Flutter)
   Payment Flow	REST API + Gateway

   Table 1: From the table, it is evident that Firestore streams offerthe fastest data retrieval for real-time operations, making themideal for order tracking and worker status updates.

   REST API calls, while slightly slower, offer structured and controlled responsesthat arebetter suited fortransactional operationslike payments and service routing.

3. ‌BASIC STRUCTURE OF CHATBOT LOGIC

   The AI chatbot is one of the most distinctive features of FoodXMarket. Rather than requiring users to manually navigate through menus and categories, the chatbot allows them to describe what they need in plain language. This is powered by Dialogflow, Google's natural language understanding platform, which is connected to the Node.js backend through a REST API webhook.

   When a user types a message such as 'I need someone to fix my pipe,' Dialogflow processes the text and identifies two things: the intent (what the user wants to do) and the entity (the specific detail

   relevant to the intent).In this case, the intent would be 'service_request' and the entity would be 'plumber.' This information is then passed to the backend, which queries Firestore for available plumbers and initiates the booking flow.

   The chatbot also handles follow-up queries such as order status checks, cancellation requests, and service rescheduling. Each of these corresponds to a separate intent in the Dialogflow configuration. The mapping between intents and backend actions is straightforward and easy to extend, making the chatbot a practical foundation for future enhancements.

   Intent Mapping Logic:

   • If intent = 'service_request' AND entity = 'plumber'

     Route to Plumber Service API

   • If intent = 'service_request' AND entity = 'electrician' Route to Electrician Service API

   • If intent = 'order_status' Fetch from Firestore orders collection

   • If intent = 'cancel_order' Trigger cancellation workflow via Express API

   • If intent = 'reschedule' Update Firestore booking document with new time slot

   Figure 1: Chat-bot Dashboard

   This logic-driven approach keeps the chatbot deterministic and reliable. Unlike open-ended AI assistants that can produce unpredictable responses, FoodXMarket's chatbot stays focused on service-related queries, ensuring users always receive accurate and actionable responses.

   This logic-driven approach keeps the chatbot deterministic and reliable. Unlike open-ended AI assistants that can produce unpredictable responses, FoodXMarket's chatbot stays focused on service-related queries, ensuring users always receive accurate and actionable responses.

   Figure.1 FoodXMarket user interface

4. ‌BASIC STRUCTURE OF THE WORKER ASSIGNMENT SYSTEM

   The worker assignment system is the operational heart of FoodXMarket. When a user confirms a service request, the application does not simply create a booking entry and wait. Instead, it immediately begins a real-time search for available workers whose service type matches the user's request. This process is handled by a combination of Firestore queries and backend logic.

   Each worker in the system has a Firestore document that includes their name, service type, current availability status, location, and active order

   count. When an order is placed, the backend queries Firestore for workers who are both available and

   are found, the system selects the one with the fewest active orders, ensuring a fair and balanced distribution of work.

   Once a worker is assigned, their availability status is immediately updated in Firestore. This change is pushed to all listening clients in real time, so the user sees their assigned worker appear on the tracking screen within seconds of the booking being confirmed. The worker, on their side of the app receives a new job notification and can accept or decline it within a defined time window.

   If a worker declines or does not respond in time, the system automatically moves to the next available candidate. This fallback mechanism ensures that no order is left unattended due to worker inactivity, which is a common failure point in simpler booking systems.

   Figure 3: Workers Dashboard

   WorkersAssignment Flow:

   Step 1 User confirms service booking through the app.

   Step 2 Backend queries Firestore for workers matching service type and availability.

   matched to the required service. If multiple workers Step 3 System selects the worker with the lowest

   active order count.

   Step 4 Worker document is updated: availability set to 'busy,' order linked to worker ID.

   Step 5 User's order document is updated with assigned worker details in real time.

   Step 6 If worker declines or times out, system repeats from Step 2 with next candidate.

   This system draws a conceptual parallel to the multiplexer-based selection in digital adder design. Just as a multiplexer selects one input from several based on a control signal, the worker assignment logic selects one worker from a pool based on availability and load. The Firestore stream acts as the real-time signal that triggers and confirms the selection.

5. ‌PERFORMANCE EVALUATION : FIRESTORE STREAMS VS REST API‌

   A key design decision in FoodXMarket was determining when to use Firestore real-time streams and when to rely on traditional REST API calls. Both approaches have distinct advantages depending on the use case, and using the wrong one can lead to unnecessary latency, resource waste, or inconsistent data.

   Firestore streams work by establishing a persistent connection between the app and the database. When any document the app is listening to changes, the updated data is pushed to the app automatically. This is ideal for features like order tracking, worker status monitoring, and chat-like interactions where data can change at any moment and the user must see changes immediately.REST API calls, on the other hand, are request- response transactions. The app sends a request to the backend, the backend processes it, and a response is returned. This is better suited for operations that require server-side validation or computation before returning data, such as processing a payment, routing a chatbot query, or registering a new user account.

   The table below presents a comparative evaluation of both approaches across different application features, helping to illustrate why a hybrid strategy was adopted in FoodXMarket.

   Table 2 Features Approach used

   ‌The results clearly show that Firestore streams outperform REST calls for data that changes frequently and must be reflected immediately in the UI. However, REST APIs remain the preferred choice for any operation requiring backend validation or third-party service integration. Using both in combination gives FoodXMarket the best of both approaches without compromise.

6. SIMULATIONSAND EXPERIMENTAL RESULTS

FoodXMarket was developed and tested across both Android and iOS platforms using Android Studio, VS Code, and Xcode respectively. The application was tested under varying network conditions, concurrent user loads, and edge cases such as worker unavailability, failed payments, and chatbot misinterpretation to ensure robustness in real-world scenarios.

The Dialogflow chatbot was tested with over 200 distinct user queries across different phrasings of service requests, order status checks, and cancellations. The intent recognition accuracy averaged above 91%, with misclassification occurring primarily in ambiguous queries that lacked a clear entity. These edge cases were addressed by adding fallback intents that prompt the user to clarify their request rather than returning an error.

The real-time performance of Firestore streams was validated by simulating concurrent order placements from multiple test accounts. Even under a load of 20 simultaneous users, the average update propagation time remained below 200 milliseconds, confirming the suitability of Firestore for production-level real-time applications.

The worker assignment system was tested across scenarios with varying worker availability, including situations where all workers ofa given type were busy. In every test case, the fallback mechanism successfully identified the next available worker or notified the user of a temporary shortage, demonstrating the reliability of the assignment logic. The payment flow, which relies on a REST API integration with a third-party gateway, was tested across both successful and failed transaction scenarios. The backend correctly handled gateway timeouts, declined cards, and network interruptions, rolling back order states as needed to maintain data consistency.

Order tracking Worker Status Chatbot Query Payment Flow User Login

Firestore Stream Firestore Stream Rest API

Rest API Firebase Auth

Cart Update Provider+Firestore

recognition accuracy, and introducing an in-app rating and review system that helps maintain service quality standards over time.

Table 3: The core features ofthe FoodXMarket

The test results confirm that FoodXMarket performs reliably across all core features. The minor chatbot misclassification rate is an expected limitation of natural language processing and can be improved over time by expanding the training dataset within Dialogflow. All other modules performed at or above acceptable thresholds for a production-ready mobile application

‌CONCLUSION

FoodXMarket demonstrates that a thoughtful combination of modern mobile development tools, cloud infrastructure, and artificial intelligence can produce a service platform that is genuinely useful in everyday life. The use of Flutter ensures a smooth and consistent user experience across platforms, while Firebase provides the real-time backbone that makes the application feel alive and responsive.

The Dialogflow-powered chatbot significantly lowers the barrier for users who may not be comfortable navigating complex menus, making the application accessible to a broader audience. The worker assignment system, with its real-time availability checks and automatic fallback logic, ensures that service requests are fulfilled efficiently without manual intervention. The performance evaluation confirms that a hybrid data strategy, combining Firestore streams for live updates and REST APIs for transactional operations, yields the best results in terms of both speed and reliability. This architectural decision is one that can be applied broadly to other mobile service platforms beyond the scope of FoodXMarket. Future work will focus on adding GPS-based worker tracking so users can see their

What this project ultimately proves is that building something useful does not require choosing between simplicity and sophistication. FoodXMarket manages to be both easy enough for a first-time user to understand within minutes and technically robust enough to handle real-world demands like concurrent orders, network inconsistencies, and varied user behavior. That balance is rarely easy to achieve, and it was only possible here because each technology in the stack was chosen deliberately and used for what it does best rather than forced into roles it was not designed for.

The decision to use Flutter, for instance, was not just about cross-platform support. It was about giving the development team a single codebase that could be maintained without duplicating effort across Android and iOS. Over time, this pays dividends not just in development speed but in consistency, since a bug fixed once is fixed everywhere and a feature added once appears everywhere. For a growing service platform where the user experience needs to remain coherent across devices, this kind of unified development approach is genuinely valuable.

Similarly, the choice to bring in Dialogflow rather than building a custom chatbot from scratch reflects a broader principle that shaped the entire project: use well-established, battle-tested tools for complex problems and reserve custom development for the parts that truly require it. Natural language processing is an extraordinarily difficult problem, and building a reliable intent recognition system from the ground up would have consumed far more time and resources than the project could afford. Dialogflow solved that problem efficiently, freeing the team to focus on the integration logic and the user experience around the chatbot rather than the underlying language model.

Firebase deserves particular acknowledgment as the technology that tied the entire application together.

Without real-time database capabilities, FoodXMarket would have felt static and disconnected. The moment a worker is assigned, the moment an order status changes, the moment a payment is confirmed all of these feel immediate and natural because Firestore pushes those changes to the user's screen without any delay. That sense of immediacy is not a luxury in a service application. It is what makes the difference between a platform users trust and one they abandon after a single frustrating experience.

From an academic and technical standpoint , FoodXMarket also offers a useful reference

architecture for students and developers who are building similar systems. The separation of concerns

assigned worker's location in real time, expanding the between the Flutter frontend, the Node.js backend, and

chatbot's training dataset to improve intent the Firebase data layer creates a clean boundary that is

easy to reason about, test independently, and scale when needed. The chatbot integration pattern, where Dialogflow handles language understanding and Express.js handles business logic, is reusable across many different domains beyond home services. The worker assignment logic, built on Firestore queries and real-time streams, could be adapted for delivery routing, appointment scheduling, or any other scenario where resources need to be matched to requests dynamically.

In conclusion, FoodXMarket is more than a project built to satisfy academic requirements. It is a working demonstration of how thoughtfully chosen technologies, when integrated with care and purpose, can solve real problems for real people. The challenges faced during development, from managing state across complex UI flows to handling Dialogflow webhook timeouts to designing a fallback-safe worker assignment system, all contributed to a deeper understanding of full-stack mobile development in practice. These lessons go beyond any single technology and speak to the broader discipline of building software that is reliable, maintainable, and genuinely worth using.

REFERENCE

1. A. Kumar and S. Gupta, Design and Development of Mobile Service Booking Applications, International Journal of Computer Applications, vol. 180, no. 25, pp. 1520, 2018.

2. R. Sharma and P. Singh, Location-Based Service Applications Using Mobile Platforms, International Journal of Advanced Research in Computer Science, vol. 9, no. 2, pp. 4550, 2018.

3. M. Patel and K. Shah, Smart Service Finder System Using Mobile Technology, International Journal of Engineering Research & Technology, vol. 7, no. 5, pp. 210215, 2019.

4. S. Lee, J. Kim, and H. Park, Development of Real-Time Service Matching Systems Using Cloud Computing, IEEE Access, vol. 7, pp. 1234512356, 2019.

5. P. Gupta and A. Verma, Online Service Booking System Using Mobile Applications, International Journal of Innovative

   Technology and Exploring Engineering, vol. 8, no. 6, pp. 100105, 2019.

6. A. Brown and T. Wilson, Cloud-Based Application Development for Service Platforms, Journal of Cloud Computing, vol. 10, no. 2, pp. 110, 2021.

7. J. Smith, User Experience Design for Mobile Applications, ACM Computing Surveys, vol. 53, no. 4, pp. 130, 2020.

8. K. Zhang and L. Wang, Design of Chatbot Systems for Service Applications, International Journal of Artificial Intelligence, vol. 19, no. 3, pp. 6775, 2021.

9. Google, Firebase Documentation, https://firebase.google.com, accessed 2025.

10. Google, Dialogflow Documentation, https://cloud.google.com/dialogflow, accessed 2025.

11. Flutter Documentation, https://flutter.dev, accessed 2025.

12. M. Chen, RESTful API Design for Scalable Web Services, IEEE Internet Computing, vol. 24, no. 2, pp. 7280, 2020.

13. S. Kaur and R. Kaur, Mobile Application Development UsingCross-Platform Frameworks, International Journal of Computer Science and Engineering, vol. 10, no. 1, pp. 3036, 2022.

14. A. Jain and V. Mehta, Location-Based Mobile Applications and Their Impact on Service Industry, Journal of Information Technology, vol. 15, no. 2, pp. 5560, 2021.

15. D. Roy and S. Banerjee, Design and Implementation of Service-Oriented Mobile Applications, International Journal of Software Engineering, vol. 14, no. 4, pp. 200210, 2022.