Skip to content

Infrastructure and Tools

Jump to bottom
Thomas Mahut edited this page Sep 30, 2025 · 19 revisions

For each library, framework, database, tool, etc (in progress)

Research Scope

The stakeholder, Fares Turki, has a preference towards a web / browser based solution for this project. Adhering to this preference is expected to yield the following benefits:

  • Users don’t need to install software directly onto their computer
  • Updates to the software can be delivered much faster (no need to update)
  • Development speed is expected to be faster, given the team’s experience with web development over desktop app development
  • Users can use the tool without having a powerful enough computer to run the simulations locally
  • Most of BIXI’s internal tooling is already web based

The team decides to proceed with a web and browser based solution based on these advantages. Researching the most appropriate tech for this project is then guided by this decision.

Frontend

React Router v7 (Framework)

React Router Documentation

Modern web development generally involves the use of a JavaScript framework / library like React, Angular, Svelte, etc. Members of this capstone team have worked with different libraries, and React is the most common among them. React is also an industry standard, and its vast ecosystem is expected to facilitate the implementation of a relatively complex UI.

React is technically just a library. It’s un-opinionated and doesn’t itself provide solutions to common web application needs. It’s common to use a framework on top of React, like React Router, Next.js, or TanStack. React Router has been in the game the longest, and it remains the most popular choice for implementing routing in React apps. This sets the team up to build a large enterprise application.

ReactRouter’s biggest weaknesses (such as lack of SEO due to client-side rendering) have been addressed in React Router v7 (in which “framework” mode supports server-side rendering). Further, Next.js is particularly difficult to host within trapping one’s self in the Vercel ecosystem, largely due to the fact that a lot of Next.js features are platform (Vercel) features.

For these reasons, React Router v7 (framework mode) is selected as the framework of choice for this project.

References:

Tailwind CSS

Tailwind CSS Documentation

Both members of the frontend team have experience with Tailwind CSS. Their experience with Tailwind’s utility-first approach is that it facilitates development (styles are defined directly in React markup, which facilitates collaboration). Styling is easier to keep consistent across the application, and there’s less CSS bloat to manage manually.

Shadcn UI

Shadcn UI Documentation

A popular component library (although not technically a library) is shadcn/ui, which itself uses Tailwind for styling its components. These components provide very good starting-points for common UI elements. By default, they are styled to appear minimal and clean, which is in the realm of Mini Metro’s UI styling choices (Mini Metro being the game that the stakeholder offers as inspiration for the UI).

shadcn/ui’s approach to individual component downloads (as opposed to a massive npm package) means the team will only import the components they actually use. The “you own the code” paradigm that shadcn/ui employs makes it easier to adjust components to our liking. Despite the relative novelty of this component library, its extreme popularity suggests that it is battle-tested.

Vitest

Vitest Documentation

Although Jest is the most mature JavaScript testing library, Vitest seems to be the most modern and best choice for our needs. Vitest is easier to set up in the context of a project that already uses Vite, and Vitest has a Jest compatible API, which helps with adoptability. For typesafe tests, Jest would require us to set up a separate, dedicated TS-to-JS transpilation pipeline because it is not compatible with Vite. Jest’s own documentation references Vitest as a potential alternative if we wish to use Vite for transpilation. Vitest in a project that already uses Vite is then expected to be a much better developer experience. You’ll even find comments on blogs for setting up Jest in a TS React project that suggest simply using Vitest in 2025. The most recent reddit threads on the topic also heavily favor Vitest.

References:

From-Scratch State Management

State management libraries like Redux and Zustand are commonly employed in web apps, but their abstraction of state management is unlikely to fit our simulation use-case. For this reason, the frontend team opts to proceed with no state management library, and to instead handle state ourselves. The team is of course open to adopting a state management library if it finds itself in a position where it would greatly benefit from one.

Mapbox GL JS

Mapbox GL JS documentation

The map-based nature of simulations, paired with the fact that the network we’re attempting to simulate is based in the real world, practically requires us to use a map provider like Google Maps or Mapbox. Based on the team's prior experience with both map providers, Mapbox is cheaper, and easier to set up than Google Maps. Mapbox also has an incredibly generous free-tier that the team can likely rely on for the entire capstone duration.

Mapbox maps have more style options, allowing for granular control over the look of the final interface. Styles can also be edited in code, whereas Google Map styles are defined in the cloud console. Mapbox also has more extensible support for overlaying GeoJSON elements, which is something the team expects to do a lot of to render the simulation.

Mapbox provides some of its service using public data from the OpenStreetMap (OSM) initiative. We are likely to use this same OSM data for generating routes in the simulation engine, which means Mapbox’s coordinate system is much more likely to line-up properly with the coordinate system used within the simulation. This is another advantage of Mapbox over Google Maps.

Mapbox is generally integrated with React apps in one of two ways; either you use the official mapbox-gl library directly, or you use a more React-specific library (like react-map-gl) that is built on top of mapbox-gl. Mapbox themselves suggest using mapbox-gl directly in your React app. Although this means more work to integrate the Mapbox map animation cycle with the React render lifecycle, the frontend team will have more granular control of the underlying APIs which might be necessary for maximizing performance. Another bonus of using mapbox-gl directly, is that the official mapbox documentation assumes this approach in their example snippets. See this example.

References:

Backend

Simulation

Table of Contents

Meeting Minutes

Simulation Meeting Minutes
Frontend Meeting Minutes
Backend Meeting Minutes

Risks
User Consent and End-User License Agreement
Legal and Ethical Issues
Economic
Budget
Personas
Diversity Statement
Overall Architecture and Class Diagrams
Infrastructure and Tools
Name Conventions
Testing Plan and Continuous Integration
Security
Performance
Deployment Plan and Infrastructure
Missing Knowledge and Independent Learning
Glossary
Mockups
UI Evolution
Logging
Metrics
VeloSim Observability & Performance Insights
User Manual
Usability Tests

Clone this wiki locally