Mo's Drones is a web app my team and I created for our final in an undergraduate software engineering class. Because I worked as a software engineer from my freshman year of college (including during the school year) until I started grad school, most web app code I've written is owned by my former company. Although this project was completed when I was still new to programming and thus is rough in some areas, I still think it's a useful demonstration of putting together a web app, front to back.

Package Tracker

The aim of the project was to build a package tracking web application for a fictional drone delivery company called Mo's Drones. The idea was that small drones would move packages between a line of depots stretching from Seward to Omaha, with a few extra depots around Lincoln. Customers can request a delivery and track their package, while an administrator can see which drones are currently in the air.  

The frontend was written in React, the backend was written in C# with ASP.NET Core, and everything was stored in a SQL Server database.

Building The Website

We started with the customer side of the website. A user can create an account, sign in, enter a destination using Google Places autocomplete, and request a delivery. The dashboard uses AG Grid to list all of their packages with the tracking number, expected delivery date, and current status. Clicking a tracking number opens a separate details page, and packages can also be found directly from the homepage without logging in.

There is also a service-area page built with Leaflet and OpenStreetMap. It places warehouse markers at all 11 depots, beginning in Seward and following I-80 toward Omaha. This made the imaginary delivery network feel a lot more real.

The same home page changes based on the account type. A normal customer gets the package dashboard, while an administrator gets a table of active drones and the package assigned to each one. React Router handles the package and drone detail pages, and local storage keeps the user's basic account information available after a refresh.

Organizing The Backend

The backend is split into controllers, managers, engines, and accessors. Controllers expose routes such as FindOrder, NewOrder, and GetDrones. Managers coordinate a complete request, engines contain the delivery rules, and accessors perform the SQL queries. We used interfaces between these layers and registered everything through ASP.NET dependency injection.

The SQL database has five main tables: Address, Account, Order, Depot, and Drone. Accounts and depots reference addresses, orders connect an account to a starting and ending address, and a drone can reference both its current depot and its current order. The database script also fills in the 11 depot locations and a fleet of available drones so the system has enough data to simulate a delivery.

I wrote the accessors using parameterized SQL commands. When a new order is inserted, the software generates a 16-character package ID, stores the addresses, and returns the new order ID using SCOPE_IDENTITY(). Unit tests cover valid and invalid lookups for accounts, addresses, depots, drones, and orders, along with account creation and login validation.

Figuring out the Delivery Route

The most interesting part was calculating what a package is doing without having real drones flying around Nebraska. When a customer enters an address, the backend sends it to OpenRouteService to turn the street address into latitude and longitude. The order is accepted only if the destination is within five miles of at least one depot.

From there, the engine finds the closest depot to the pickup and destination using geographic distance. The estimate assumes 20 minutes of flight between neighboring depots, 10 minutes to transfer a package at each stop, and a drone speed of 30 miles per hour for the trips between a customer and a depot.

The package status is generated from a timeline instead of being manually stepped forward. Depending on the current time, an order can be waiting for pickup, flying to a depot, sitting at a depot for a handoff, flying to the customer, or delivered. The same timeline is used to assign an available drone from the correct depot and update the administrator dashboard.

A tricky part here was that a route can travel either direction through the depot list. Going from Seward to Omaha increments the depot index, but a return delivery has to decrement it. A few lines of index math decide both which depot name appears in the package status and which depot should supply the next drone.

Connecting Everything

The final application joins several pieces that were fairly simple on their own. React collects an address, ASP.NET passes it through the manager layer, OpenRouteService converts it to coordinates, the engine validates and estimates the trip, and the accessors save it in SQL Server. Later requests rebuild the current package and drone state for the two dashboards.

Getting the complete delivery flow working gave me a lot more respect for the boring-looking glue code in full-stack applications. From what I observed in my class, that glue code is also the thing that trips the most people up. I don't have a demo unfortunately, but if you're interested in the source code you can take a look here.