Asset Management Dashboard is a full MERN stack application for the management of assets and shipments of assets (including all CRUD operations) with a modular structure and centralized dashboard. Formerly known as Product Management Portal.
This project was developed in collaboration with Evolution Engineering & Energy Technologies as a central dashboard for the management and tracking of company assets and shipments. The goal was to build a custom application that would help to replace and amalgamate the fragmented, 3rd party management solutions currently in use. Prior to this application, the company did not have a reliable way to track and maintain history, status, rental assignment, or ownership (among other details) of these products.
- Central dashboard with global search
- Listing, filtering, and creation of assets and shipments
- Map views for asset locations and shipment routes
- Support for file attachments to shipments
- Error-checking and schema validation of assemblies
- "Shopping cart"-style tools for creating and managing assemblies and shipments
A live demo can be found here.
You may use the following credentials to log in:
Username: jsmith
Password: password1
Note: The live demo is hosted on a free Heroku server which shuts down after 30 minutes of inactivity (and deletes files with it).
- You may need to refresh the page multiple times to allow the server to start before login or API calls can go through
- Some attachments may show up under a shipment's details, but attempting to view them results in a spinner because Heroku deleted the files as temporary
- To test attachment functionality, upload a new attachment and immediately view it
Demo video / project overview: YouTube
- ReactJS
- Material-UI (component library)
- JavaScript
- TypeScript
- Node.js
- MongoDB
- Mongoose (MongoDB object modeling tool)
- Express.js
- Redis (data caching)
- Swagger UI (API documentation)
Further details may be found in the frontend folder README.md and the backend folder README.md.
Node.js version >= 14 is required to run the API server due to the usage of optional chaining.
The package.json file in the root project directory provides a few convenience scripts atop the normal ones. The simplest way to get started is to run
npm run-script launch
which will install all frontend and backend dependencies, build the frontend, run the server, and serve the frontend production code at port 3000 (by default) on localhost.
Building without running can be accomplished by running
npm run-script build
To manually launch the frontend from the frontend directory, ensure dependencies are installed with npm install, then a development build can be launched using npm start and a production build can be built using npm run-script build and served using serve -s [build directory] -l [port].
To manually launch the backend server from the backend directory, ensure dependencies are installed with npm install, then the server can be started with either node server.js for a single invocation, or nodemon server.js for restarting the server when files are updated.
Both the frontend and the backend expect .env files with necessary values to run. See here for the example frontend .env and here for the example backend .env.
- If you wish to utilize data caching for the API server, ensure you have a Redis server setup and running, and its URL in the backend
.envfile (see sample .env)
- Users must manually be created in the database in order to log in, there is currently no user creation implementation
- Sample data is provided and can be loaded into the database using the provided
/loadPOST endpoints of each collection - Additional assets, assemblies, and shipments can all be created through the GUI
- The method by which users are currently authenticated is not suitable for production and all instances of user identification in the frontend will need to be retooled (for example user name display and how users are tied to the assets they create)
- The team chose to forego a robust authentication system due to the company utilizing SSO / Microsoft Active Directory as their primary user authentication strategy and integration was deemed outside the scope of the project
- The current method is a very simple check against passwords that are stored in the database in plaintext
- If the user is successfully authenticated, the server sends back an encrypted JSON object that the user sends back in the body of all PATCH or POST requests in order to authorize themselves
- This encrypted object is simply stored in LocalStorage and while it is somewhat secure due to its encryption, it is not suitable for production, nor is plaintext password storage
- Additionally, API routes are not thoroughly protected from unauthenticated users
- When this refactor is completed, any frontend page using the custom
useLocalStoragehook and any backend page using theencrypt/decryptfunctions and/or PATCH/POST endpoints that use the valuereq.body.userwill need to be updated for the new authentication scheme
- It's likely that the usage of the database is the area of the project where the most optimization could occur
- For one, the data we are storing is pretty highly relational but we have chosen to use MongoDB (a NoSQL database)
- This structure required us to store ObjectId references and
populate()them at query time (similar to a SQL JOIN, which NoSQL database are not optimized for) - This both complicated our queries and likely hampers performance
- This structure required us to store ObjectId references and
- It's possible this could be remedied by denormalizing the database
- However, the nature of the data — in particular, the recursive relationship between assets and assemblies (parents in the same collection) — may make a SQL database, such as PostgreSQL, more desirable
- As a result of this additional complexity, the major POST and PATCH endpoints of both modules generally perform many queries in order to properly update all the circular references, children, etc.
- These complex endpoints are wrapped in transactions in order to ensure atomicity and mitigate some of the problems
- However, the current logic is fairly complex, likely still has errors, and may not be as performant as it could be
- The current styling is not optimized for phones or other small screens
- While some responsive components (such as Material-UI's
Grid) and CSS properties such asflexwhere used throughout the project, many pages and elements still do not render correctly on small screens
Frontend components are documented throughout the project using inline comments, JSDoc, and prop-types.
The backend server API documentation is written in OpenAPI and hosted at /api-docs of the server URL using SwaggerUI.
Full license available here.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent