Checkmate
Checkmate 2.1
Checkmate 2.1
  • Welcome to Checkmate 2.1
  • USER'S GUIDE
    • Installing Checkmate
    • Using Checkmate
    • Uptime monitor
    • Pagespeed monitor
    • Infrastructure monitor
    • Status pages
    • Viewing incidents
    • Maintenance mode
    • Server settings
    • User settings
    • Server monitoring agent
    • Troubleshooting
    • Server requirements
  • DEVELOPER'S GUIDE
    • Contributing to the code
    • General project structure
    • High level overview
Powered by GitBook
On this page
  • Front end
  • Back end

Was this helpful?

Edit on GitHub
Export as PDF
  1. DEVELOPER'S GUIDE

General project structure

PreviousContributing to the codeNextHigh level overview

Was this helpful?

This is a brief overview of the project structure. If you are a serious developer and would like to learn how Checkmate works in detail, please check :)

The Uptime Manager product uses the MERN stack, which is to say that the project uses:

  • React on the Front End via Vite

  • Express on the Back End via NodeJS

  • MongoDB for data with Mongoose for data access

Front end

The project uses the (MUI) which allows us to build with a minimum of fuss. The library is highly customisable and the project makes heavy use of the Theme concept and follows MUI’s paradigm to avoid writing excessive CSS. The overriding goal on the Front Eed is to write maintainable and scalable code. If you find yourself writing lots of CSS to customize a component or are having to set a value often like font size or color you probably should be using the theme. When making changes to the Front end please always keep future developers in mind. Will they know how to make changes to your code? Is your code modular? If a dev makes changes elsewhere in the app will your component be affected? If the team makes a theme change like font size or primary color will your component be updated as well?

Back end

The back end of this project is not especially complex and is built around Express. The back end is a RESTful API and the .

The application consists of several main conceptual models:

  1. User

  2. Monitor

  3. Check

  4. Notification

There are several supporting models as well.

  1. AppSettings

  2. InviteToken

  3. Team

All requests are based around these models and manipulation of their data. In general the models interact in this fashion:

  • A User has many Monitors

  • A Monitor has many Checks

  • A Monitor has many Notifications

A User can create a Monitor. Monitors are enqueued in the JobQueue, and their target URLs are queried when they are dequeued. When the query is complete, a Check is created that records information about the request. A User may attach a Notification to their Monitor, if the Monitor’s status changes then the user will be notified by the method specified in the Notification

this link
Material UI Components
documentation can be found here