Divine Star Project Manager

Table Of Contents


DSPM aka Divine Star Project Manager is a project management web software. It's a single page application built with a MERN stack. It can be either used as a stand alone application or you can use it's API. It is meant to be an application that is deployed by the user on their own server akin to something like GitLab.

The goal of DSPM is to create an enjoyable and easy to use project management software for individuals, organizations, as well as their clients. The word I use to specifically describe the experience that I wish to create with this project is 'zen'. Meaning I intended to create an incredibly simple but powerful experience.

One of the coolest features I feel is being able to add notes, comments, and content to projects. tasks, and bugs using Markdown.

Current Features
  • Secure sign in and authorization with JWT tokens.
    • To be truly secure the instance of DSPM must be on server with a valid SSL certificate.
  • Create different project categories. Both private and public.
  • Create projects for each category.
    • Each project has it's own Task and Bug categories.
    • Each project has a comments and note section as well as a content section.
  • Create tasks for each project.
    • Tasks can be either simple to-dos, features, and or development goals.
    • Each task has a comments and note section as well as a content section.
  • Create bugs for each project.
    • Bugs are the un-intended problems that arise in a project.
    • They are handled separately so you can restrict who can see them.
    • Each bug has a comments and note section as well as a content section.
  • Create content and write comments using markdown.
  • Caching server side using Redis and local caching using IndexDB.
  • An API that can be used to access all data from the server. Thus allowing a headless mode if need be.

This project is still in development. But is close to an official release. Here are some features that are to be added.

Features In Development
  • Assign users to projects, tasks, and bugs.
  • Upload file attachments to comments and notes.
  • Invite users to join through a generated link that expires.
  • Build in email support through something like courier.
  • Add Auth0 support.

Features that I really want to implement but will be done later.

Desired Features
  • Add tags for projects, bugs, and tasks.

    • There would be global levels tags and project level tags.
    • Separate tag groups for each that could be used to query all related content.
  • Add a notebook section separate from the projects section just for notes.

    • Could have private and public notes. Such as shared documentation for a company.
  • Create an easy way to export all the content.


Full List Of Technology Used
  • MongoDB
    • Used for all data storage.
    • The creator of the instance of DSPM must provide a valid connection URL string.
  • Redis
    • Used for caching data on the server side.
    • The creator of the instance of DSPM must provide a valid connection URL string.
  • IndexDB
    • Used for client side caching of API responses.
  • NodeJS
    • Used to create the backend of the application.
  • Express
    • Used to create the API for the application.
    • Also various middleware from express is used. To do things such as create cookies and parse JSON response bodies.
  • TypeScript
    • Used to write all of the code.
  • React
    • Used to create the UI for the main application.
  • Material UI
    • The component library that is used.


The overall design of the codebase for this project follows the Model View Controller programming pattern. Data is stored in a database, data is accessed and worked upon on the server, and the representation of the data is presented on through the front end. The single place of truth is always the database.


Caching is a big part of the overall design of this program. All needed responses from the server are stored in IndexDB on the client side. Only when something needed to be refreshed a new data is retrieved and cached. This is to keep the load times on the client side really fast for all ready loaded content as well to reduce the load on the server.

Back End

The backend API is designed to be a RESTful based API. Meaning all the responses and request are uniform, stateless, and can be cached easily.

The API itself is written with mostly a functional pattern with the use of some class objects that are passed to the functions. Each end point is it's own function that can be individually worked on. Upon each API request a JWT token must be provided either through a cookie or through the API call itself. If the JWT token is valid and has the needed information the server will begin to process the request. Before each request is processed it's request body is checked to make sure that it's structure and variables types match the expected values. Once that is all good the request is finally executed. If caching is enabled on the server the response will be cached if need be and then the response will be sent.

I think I did do one thing unique with this API and that is by providing a means to add more operations to a single call to limit actual request to the server. For instance if a add or update a project and you set a special flag in the request it will return the success message as well the new list of projects to be displayed. So a second request to the server does not need to be made and the cache on the server side is automatically updated.

Front End

I went with Material UI as the base for the design of the application.

Some of my design principals for the project are:

  • Keep the UI as decluttered as possible.
  • Make everything easy to find.
  • Separate operations into different screens.
  • No sudden cuts to a different screen. All must be smooth transition.
  • Keep the colors and backgrounds a "relaxing" color that is easy on eye strain.


Some Additional Notes

The config for the application is all stored in the local .env file. When the program is first started it will check to see if it is properly configured.

If it is not it will prompt the user to go through a configuration process. There they can set up the database and create the first initial admin user.

The config and the end points for it will only be created if it can not establish a connection to a MongoDB instance and if when it connects to the MongoDB instance it does not find any admin users.


No alt provided.
No alt provided.
No alt provided.
No alt provided.
No alt provided.
No alt provided.
No alt provided.
No alt provided.
No alt provided.
No alt provided.