MagicRoutes

Hello everyone!

Welcome to Devlog #3!

Over the last work session, I mainly focused on improving the frontend and making the website feel much more polished.

I redesigned a large part of the UI, refining the overall layout, improving the landing page, and making the interface much cleaner and easier to navigate.

I also added dedicated Pricing and About pages to give the project a more complete feel.

Alongside the frontend improvements, I continued optimizing the backend. I profiled some of the slower parts of the solver and made a number of improvements that reduced the overall solve time even further.

I also spent some time cleaning up the project structure, improving the codebase, and fixing a number of smaller issues that I noticed while using the application.

This update comes after around 10 hours of work.
On the backend side, most of the time was spent benchmarking the solver after every optimization to make sure each change actually improved performance without affecting solution quality.
The project is finally starting to look closer to what i want as a final product, and I’m excited to continue adding more features and polishing the overall experience.

You can check out the website at: magicroutes.tech

As always, I’d love to hear any feedback or suggestions you might have.

That’s all for Devlog #3!

Hello everyone!

Welcome to Devlog #2!

Over the last work session, I focused on turning the project into something that actually works end-to-end.

The biggest milestone was connecting the frontend with the backend, so now the UI can communicate directly with the solver instead of relying on placeholder logic.

I also spent a lot of time improving the backend’s performance. While everything was working, solving larger problems was taking much longer and I wanted to make it faster. After optimizing some parts of the solver, I managed to significantly reduce the solve time.

On the frontend, I polished the interface and improved the overall user experience. I still have some ideas for the frontend which I will probably finish by the next devlog.

This update comes after around 12 hours of work. Unfortunately, I forgot to post earlier, so only 10 hours will be recorded due to the logging limit (maximum of 10 hours per post).

The hardest part wasn’t actually the optimization, it was deploying both the frontend and backend on Oracle Cloud and connecting it to the domain.

Getting everything configured correctly, setting up the server, and making sure the services could communicate properly took me an entire day.

Those hours aren’t included in this log since I spent most of that time working in the terminal and navigating the OCI interface rather than writing code.

Once the deployment was working, I could finally focus on optimizing the backend, which also took a fair amount of time because the solver was initially much slower than I wanted.

You can checkout the website at: magicroutes.tech

That’s all for Devlog #2!

[The benchmark results in the images are just placeholders, I have not updated them with my solver’s actual results]

Hello everyone!

A few years ago, I wrote a C++ program that solves the VRPTW (Vehicle Routing Problem with Time Windows) pretty well.

(For those who don’t know, the Vehicle Routing Problem with Time Windows (VRPTW) is a problem where a fleet of vehicles has to deliver to a number of customers. Each customer must be visited within a specific time window, every vehicle has a limited carrying capacity, and the goal is to find routes that satisfy all these constraints while minimizing the number of vehicles used and the total distance or travel time.)

The solver had been sitting around for a while, so I decided that I might as well build a frontend and backend around it to make it into a full-fledged project.

This is the first devlog I’m publishing and I’ve just finished making the backend API using Drogon, a C++ library for building high performance REST APIs.

I also integrated my old solver with the backend. Originally, the code only contained the core algorithm, but I needed it to support a wider range of user inputs. I added API parameters for things like vehicle capacity, depot location, and custom distance matrices, then passed those inputs directly to the solver which I changed to make use of these inputs.

The hardest part was to adding support for the backend API to also take in a CSV file for the distance matrix and use that instead of the default Euclidean distance calculation. I also added an option for calculating distances using the Haversine formula which is used to calculate distances on the Earth’s surface. Whenever the user gives latitude or longitude coordinates, I use this formula instead of the normal Euclidean distance formula.

For the frontend I used Leaflet and OpenStreetMap to plot all the data points on the real-world map.

You can check out the website here: https://magicroute.vercel.app. The frontend isn’t connected to the backend yet, so most of the solving part is just a placeholder.

I would love to hear your suggestions or ideas so if you have any feedback, please let me know.

That’s it for this devlog and I’m looking forward to posting more devlogs!