FreshExpress

Live demo

The web application is live as a portfolio demo, with a sample catalogue, local images, customer registration, and a MySQL database. Visitors can browse without signing in and create an account to try the customer flows. It is not a real store: do not make real purchases or enter sensitive personal data. The Express API was developed for a specific part of the school assignment and is not currently deployed or running.

Context and scope

FreshExpress began as a class assignment and was later adapted for publication as a full-stack portfolio project. It simulates a grocery ordering and delivery platform with distinct workflows for customers, delivery staff, and administrators. The public deployment focuses on demonstration and safety, not commercial operation.

Web application

The main application uses Astro and TypeScript with server-side rendering. It includes product browsing and search, a cart, checkout, user accounts, order history, and tracking. Separate interfaces support the delivery workflow and administration of products, orders, users, and configuration.

• JWT authentication with passwords processed using bcrypt.
• Role-specific access for customers, delivery staff, and administrators.
• MySQL data layer using connection pools.

Complementary REST API

As a specific goal of the school assignment, I developed a separate REST API using Node.js, Express, and MySQL in a second repository. Its code includes health, active-company, and statistics endpoints. It demonstrated the separation between a web client and an independent HTTP service, but the API is not deployed or part of the live demo.

Data and deployment

The web repository includes consent, anonymisation, and statistics functionality, plus SQL scripts to create the schema and load a sample catalogue without predefined users. The demo runs Astro and MySQL in containers behind an HTTPS web server. Prediction and recommendation experiments are not part of this deployment.

Future improvements

The assignment aimed to demonstrate ordering and delivery workflows, not to run a real store; implementing payments or external commercial services was therefore outside its scope. If a business wanted to use FreshExpress, these capabilities would need to be developed and validated before production use. A first step would be email verification during sign-up using a one-time code sent through an email service (for example, Gmail), with expiry and limits on attempts and resends; the account would activate only after validation.

• Real payments through a payment provider without storing card details in the application, plus cancellation and refund handling.
• Inventory, availability, and up-to-date pricing checks before confirming an order.
• Secure password resets using a temporary link sent to the verified email address, and order-status notifications.
• Tests for critical flows and a security, privacy, and legal review before any commercial use.