Frontend Architecture
Relevant source files
The following files were used as context for generating this wiki page:
The Fleet frontend is a Single Page Application (SPA) built using React, TypeScript, and Hooks. It serves as the primary interface for IT and security teams to manage endpoints, policies, and vulnerabilities. The architecture is designed to be modular, leveraging a centralized directory structure and established design patterns to ensure scalability and maintainability.
Sources: frontend/README.md:1-5, handbook/product-design/README.md:18-22
Core Technologies and Structure
The application follows a strictly defined directory structure to encapsulate components, styles, and logic. Every component typically resides in its own directory containing the React component file, styles, tests, and an entry point file.
Directory Organization
| Directory | Description |
|---|---|
components/ | Global React components rendered by pages, receiving data via props. |
context/ | React Context API implementations for global entities like the logged-in user. |
interfaces/ | TypeScript interfaces for reusable Fleet entities to ensure type safety. |
layouts/ | General app UI structures (headers, sidebars); uses CoreLayout. |
pages/ | Components rendered by the router, handling URL-specific logic. |
services/ | CRUD functions linking the frontend directly to the Fleet API. |
utilities/ | Reusable helper functions (CSV conversion, debouncing, error formatting). |
Sources: frontend/README.md:38-112
Design Patterns
Fleet utilizes a "wireframe-first" approach for all UI changes. This process involves creating Figma wireframes before implementation to ensure the strategic "why" is addressed. Product designers use a starter file template in Figma to communicate reviews and development progress.
Sources: handbook/product-design/README.md:73-88
Component Architecture
Components are designed to be self-contained. The use of an index.ts file in each component directory allows for cleaner imports by referencing the directory name rather than the specific filename.
The diagram shows the internal structure of a component directory and how components flow from the router to the UI.
Sources: frontend/README.md:43-62
Data Management and State
State management in Fleet is handled through a combination of React Hooks and the Context API. Global state, such as the currentUser, is maintained in the context/ directory to be accessible across multiple pages and components.
Global Context Implementation
The app.tsx context file is a critical piece of the architecture, providing shared information that is required throughout the application lifecycle.
API Integration
Communication with the backend is facilitated by functions in the services/ directory. These functions wrap Fleet API endpoints and provide a clean interface for page components to perform CRUD operations.
Sources: frontend/README.md:70-75, frontend/README.md:96-98
Navigation and Routing
Routing is managed by React Router, which maps specific URLs to Page components. The router/ directory contains the route definitions and a paths.ts file that holds application paths as string constants.
Routing Flow
The sequence diagram illustrates the flow from a user navigation event to data fetching and UI rendering.
Sources: frontend/README.md:80-94
Static Content Generation
While the main application is a React SPA, Fleet uses a specialized build process for the website and documentation. The build-static-content.js script generates HTML partials from Markdown and YAML sources.
- Markdown Processing: Documents are compiled into HTML partials and metadata (like page order and title) is extracted from meta tags.
- Sails Integration: The compiled data is injected into the Sails app configuration (
sails.config.builtStaticContent), making it available to server-side controllers. - Schema Tables: The build script merges osquery schemas with Fleet overrides to generate documentation for various tables.
Sources: website/scripts/build-static-content.js:31-105, website/scripts/build-static-content.js:1016-1050
Testing and Quality Assurance
The frontend architecture includes a comprehensive testing strategy:
- Unit/Integration Tests: Located alongside components (
*.tests.tsx) and executed via Yarn. - E2E Testing: Managed by QA Wolf to handle complex user flows and release validation.
- Storybook: Used to visualize and document global components in isolation (running on port
6006).
Sources: frontend/README.md:15-36, frontend/README.md:118-132
The Fleet frontend architecture emphasizes strict directory boundaries and the separation of concerns between layout, data services, and global state. By combining a React-based SPA with a robust static content generation pipeline for documentation, the system maintains high technical precision while remaining "outsider-friendly" for contributors.