This project was carried out as part of the TechLabs “Digital Shaper Program” in Aachen (Winter Term 2022/23)
Blogpost Group 9 — Tafel Route
This is the blogpost of Group 9 of this semester’s TechLabs journey. Our project was initiated by TechLabs itself to increase the efficiency of Tafel’s deliveries. We hope our code will contribute to the continued success of the Tafel and we are keen to receive any feedback from you on how we can further improve the website.
1. Introduction
The Tafel is a German non-profit organization that operates in major and also minor cities across the country with the aim of reducing food waste and alleviating hunger among the less fortunate. To achieve this, the organization collects surplus food from restaurants, bakeries, and supermarkets that cannot be used or sold, such as items that have exceeded their best-before date or that were purchased in excess. However, the process of collecting and distributing this food is currently unstructured and lacks efficiency. Our website aims to establish a platform for donors to provide information about the type and quantity of food they can supply on a specific date, and for Tafel’s responsible drivers to derive a delivery route from this information. In this way, the distribution of food can be made more streamlined and efficient.
2. Method
Our web application was built using the MERN tech stack (MongoDB, Express, React, Node).
This web application is made available to three different users: driver, store employee and admin.
2.1 Front-End
React was used to build the user interface by using components. For example, forms were used to send information to the server and tables were used to display information from the server.
2.1.1 HTTP Requests
Meanwhile, Axios was used to make HTTP requests from the browser to the server. Axios is a popular JavaScript library used for making HTTP requests from a web browser. For example, a store employee can make a new appointment using an HTTP POST request, edit an existing appointment using an HTTP PUT request and delete an appointment using an HTTP DELETE request. Also, our web application can access the optimized route for the Tafel driver by using HTTP GET requests.
2.1.2 User Authorization
The public pages of this web application are the homepage, the registration page and the login page. Upon logging in, the JWT token received from the server is stored in the local storage and the user is routed to the web pages they are authorized to have access to. This is done by decoding the JWT token. The user can navigate to these web pages using the navigation bar. When the user logs out, the JWT token is cleared from the local storage.
2.1.3 Google Maps API
The Google Maps API are used in the driver page to calculated the best route between the multiple pick-up locations. First, the getCurrentLocation() function are created to use a feature called geolocation to get the current location of the user’s device. This function returns the user’s current latitude and longitude coordinates. The calculateRoute() function takes an array of locations, including the user’s current location if available. It then uses the Google Maps API to calculate the best route between these locations. The route includes both the start and end points as well as any additional points in between. The function then updates the state of the application with information about the route, including the distance and duration of the trip.
2.1.4 Styling
The styling for the user registration, OTP verification and user login was done using templates from Material UI. For most of the site’s components, we used content imported from the MUI material library and wrapped it in <StyledEngineProvider injectFirst>. This allowed us to easily apply MUI’s predefined styles and create a consistent visual experience across the site.
In the Google Maps component, we chose to design it using the Chakra UI tool, wrapping it in a <ChakraProvider theme={theme}> component. This provided us with a simple and elegant way to design and customise the display of Google Maps. Home page and individual page title background images from Unsplash to make each page title more eye-catching.
2.2 Back-End
2.2.1 MongoDB
MongoDB is utilized as the database provider in the backend, which comprises three components: users, restaurants, and appointments.
2.2.2 Schema Structure
During user registration, users can choose which organization (i.e. either Tafel or a bakery, restaurant or supermarket) to be assigned to. If the user is a driver for the Tafel, they can obtain their delivery route from the website later. If the user is an employee of a bakery, restaurant, or supermarket, they can provide information about the to-be-donated food online. Therefore, the user directory contains not only name and email address but also information on type (“Driver”, “Employee”). The restaurant container includes information about each food donor entity, such as name, address, coordinates (longitude, latitude), contact information, and a logo image. Each restaurant is also assigned its employees.
If a food donor decides to supply food, they create an appointment for pickup, including pickup date and time, as well as the type and quantity of food.
2.2.3 Swagger & ThunderClient
Initially, we used “Thunder Client” to test requests on our local machine. Then, we utilized “Swagger.io” to deploy it on a temporary website for the front-end team to test requests.
3. Project Result
In this section, the functionality of every web page in our web application is demonstrated.
Our web application is accessible through the following link: https://tafel-route.netlify.app/
3.1 Sign Up
In this page, a new user is able to register as either a Driver or a Store Employee by making their choice using a drop down menu. New users are not allowed to register as an admin as this is carried out internally. By providing their first name, last name, email address and password, a new user is able to register a new account.
The password must have 8 to 24 characters, at least one uppercase letter, one lowercase letter, one number and one of the following special characters: ! @ # $ %. The confirmed password must match the password. If these conditions are not met, the sign up button is disabled, thus not allowing the new user to register.
3.2 Verify OTP
Upon clicking the SIGN UP button in the registration page, the new user will be directed to the Verify OTP page. Here, the new user need to enter the email that they registered with and the one-time password. In a real life setting, the new user will be sent the OTP through email. However, that is not implemented in our web application and the default OTP for new user registration is 999999. Despite that, this feature can be implemented, if needed.
3.3 Sign In
A registered user is able to sign in using their registered email and password. The user gets an error message if the login attempt failed. Upon successful registration, the user gets routed to the web pages they are authorized to access.
3.4 Driver Page
Only users registered as a driver is authorized to access this page after logging in.
At the top of the page, the driver’s name is displayed. Next to it, the user can select the collection date from the drop-down menu. After the date is chosen, a list of pickup points along with information about the food items, quantity and unit is displayed. At the bottom of the page, a Google Map with a suggested optimized route is displayed.
3.5 Store Employee Page
Only users registered as a store employee is authorized to access this page after logging in.
The name of the logged in store employee is displayed at the top of this page. It features a table that displays the food items that are available for pick up. The table includes columns for the item name, amount, and unit of measurement. To add a new food item, store employees simply need to click on the “Add Item” button on the store page. Once they have filled out the form, they can click the “Add” button to add the item to the table. If a store needs to edit or delete an item, they can click on the appropriate button in the table. This will either open a form where they can edit the information or a confirmation dialog box to confirm the deletion of the item.
3.6 Admin pages: Stores and Drivers
Only the admin is authorized to access this page after logging in.
These two pages are very similar in nature and serve to manage the registered users. One page is used to manage all driver accounts, while the other is used to manage all store employee accounts.
Firstly, by providing the first name, last name, email address and password, it is possible to add a new user (driver or store employee). Other than that, a list of all registered users is displayed in a table. It is possible to edit the first name, last name or email of all of these registered users. Besides that, it is also possible to delete a user.
3.7 Sign Out
In order to sign out, the user has to do is click on the sign-out button in the navigation bar. Upon clicking the sign-out button, the user will receive a message that the logout was successful and the user is able to navigate back to the homepage. As our web application cannot automatically log out a user after a certain period of time, it is very important for the user to log out for security reasons and to allow a new user to log in.
4. Conclusion
In conclusion, with our website, we hope to improve the operational efficiency in the Tafel organisation. By connecting food donors to Tafel through an online tool, we enable restaurants, bakeries, and supermarkets to provide information on their donations in terms of food type and capacity. This information can on the one hand be used to identify patterns in surplus food, leading to increased efficiency in food procurement and processing, and thus, less food waste. On the other hand, our platform simplifies the task of route planning for drivers, who can generate a route automatically in the system and export it to their mobile phones to use Google Maps.
Overall, we believe that our platform can bring about positive changes to the Tafel organization and help them in their mission to reduce food waste and feed the hungry.
4.1 What would you do if you had a lot more time?
General features:
- Suggesting the optimal vehicle (for example: car or a minivan) based on the weight and size of food or produce to be collected on a particular day
- Record the food inventory
- Instead of the default one-time password (OTP) for new user registration being 999999, the new user receives a unique OTP, thus successfully verifying their email.
Back-End:
- To improve the functionality of the appointment system, a feature can be added that checks the employee IDs when changing appointments. This feature would ensure that only members of the same organization can make changes to appointments. For example, if Employee 1 created an appointment, Employee 2 who works at the same restaurant should be able to change that appointment. This would help to maintain the integrity of the appointment system and prevent unauthorized access to appointment information.
Front-End:
- Using Dijkstra algorithm to make the route more efficient, especially when there are multiple points that need to be connected, the google maps API tend to calculate in the order in which the addresses are entered.
- Add a feature in the maps where drivers can send routes on their mobile phones
4.2 How could the results be improved?
- In the front-end, there are several instances where the same code is repeated in several different files. A concept could have been developed to implement reusable components in order to create an overall better-structured, modular software which supports reusability.
- The admin should not only be able to manage the users (driver and store employees) but also the appointments and restaurants.
- The store employee should be able to add and edit their respective store through the store page.
Team Members:
Mentors:
- Marmik Thakkar
- Anujoy Chakraborty
