Orgnocal
Summer - Fall 2024
Provides users a project management service with the freedom to express goals in their projects with different dashboard views and create meaningful relationships between their project items, whether it be they are working in an organization (org) or just as a stand-alone user.
A Spark of an Idea
I got the idea to create an application like Atlassian's Jira/Confluence, GitHub's Projects, Trello, Monday.com and a number of project management services also had an impact on this product. Although I didn't want it to purely be a clone of these tools. I have used the majority of these tools and I've seen what has worked and hasn't worked so well in applications. I thought most of these tools in general lack solid relationships between projects and their underlying issues/tasks. Also several of these tools have limited ways of visualizing items in a project. I really wanted to expand on the concept of "Views" for a project with the user being able to select from a wide variety of views - that can unlock different features in the application. I also wanted this tool to be less of a focus on pure software development and allow other specialties to have a tool that could be easily understandable for them.
Main Source of Inspiration
Honestly, I took a lot of inspiration from a lot of different sources. The top source, was GitHub Projects, which I use daily. A lot of my ideas for this project also spawned out of the limitations of project management in Spotilight.
Overview
Orgnocal is an enterprise project management system with multi-user support. At a broad scale users can create projects containing tasks that can be viewed in several ways. User's can create organizations/groups/teams (called "orgs" in the application) to organize users for one or more projects or an environment. Projects can be created by a user and assigned to orgs or individual users.
View Relationships
One of the most important aspects of this tool is the ability to view different relationships between the projects and tasks. A user can view and alter progress on the Board page. A user can view tasks from a grid or tabular view to understand important details about each task. To get a sense of deadlines in a project, a user can use Calendar or Gantt views to see a timeline for when tasks should begin and be completed by. They have the ability to archive tasks, if they want to hide a task from the main screen, but still be able to see past tasks they have completed. The "Dashboard" view displays progress on how the project is going with charts and what tasks haven't been completed and what is overdue. At a smaller level, a user can even have nested tasks within a task, where they get a feel for parent/child relationships between tasks. The "Hierarchy View" in the application best shows this relationship, representing a layout of different layers in this bureaucratic structure.
The Production & Diagrams
This project was developed with a React front-end using a number of frameworks, including TypeScript, Next.js, Redux Toolkit, and Tailwind. Redux Toolkit made it fairly simple to update content on the page, by invalidating identifiers or content once a part of the data was updated on the back-end.
For the back-end I landed on using TypeScript as well, specifically Express to communicate with a Prisma ORM (Object-Relational Mapping). I found Prisma's implicit many-to-many relationships especially convenient without the need to specify a ton of pivot/join tables. I ended up making some seed data to test out the database which came in pretty handy. As I could easily wipe all the database table data and just regenerate the database by using the seed data. This made working with a fairly complex data schema quite easy. You can view my Entity-relationship diagram (ERD) to the left.
AWS Architecture
I ended up diving pretty deep into AWS services to deploy the application. Just to name a few I used EC2 for the back-end (and PM2 to continuously keep Express running), a PostgreSQL RDS database, AWS Amplify to CI/CD the front-end, Cognito to authenticate users, and a Lambda function for posting user data to RDS. If you want to know the complete list of services I used and the architecture of the tool, see my AWS architecture diagram to the right. Throughout the integration and deploying my app with AWS, I added a few new tools to my arsenal and I experienced a load of challenges - the most complicated piece by was debugging my Lambda function. I have public and private subnets contained in the cloud. EC2 is contained on a public subnet that communicates to the two private subnets containing RDS. Amplify reaches EC2 through API Gateway. Users communicate to the back-end server through Route53 and Internet Gateway.
Application Challenges
By far, the most challenging part with the "Hierarchy" view. This representation was difficult to manage in a front-end data structure and I needed to change my ERD to ensure this view worked correctly with nested tasks. I think the drag-in-drog approach and layering system added to the challenge. In some ways I still don't feel like the view is perfected yet, and I have considered changing it. Originally, I was thinking about making a Tree View for this visualization, but I don't think it captured the similar layers between the different hierarchy structures well.
A Challenge with Lambda
Another major challenge, and a rabbit hole at that, was debugging my AWS Lambda function that is triggered on a AWS Cognito user getting created. I had some troubles with creating a user initially with Cognito and registering them in the database. In my AWS architecture, I set-up a Lambda function to be triggered once Cognito adds a user to its user pool, where Lambda sends the user's Cognito ID and PII (Personally Identifiable Information) registered in Cognito to the RDS database. Lambda then sends this information through the API Gateway, to EC2 which is then sent to the private subnet where my RDS database lives. Through debugging the problem I had scrubbed through every layer of this communication channel and used CloudWatch to get reports on error statuses. Initially, the problem appeared to be that the endpoint I was calling in Lambda was being registered as a 500 code in API gateway, to later there being an issue with the EC2 not accepting the request, and RDS not being able to add the user at the specified identifier. I eventually dug into the private database by using EC2 as a bastion host and found the seeded data had caused an issue with how I was incrementing the IDs. It was very rewarding to see my progress resolving each problem along the way and eventually add a new user to RDS.
The Outcome
I think this tool is quite versatiles and accomplishes my personal goals. I could see past teams I've worked with finding this beneficial as this would better fit some of our desires to see relationships between tasks and projects. As far as the organization concept goes I think it works fairly well, but can be fine tuned to be more streamlined. In general I think navigation is pretty snappy, you can get to project and org pages quickly. One of my other goals for this project was to make this application feel as close to an enterprise project that I've completed on my own terms. I do feel like this touches the bases on making it on the level of an enterprise application and this parallels a few of the projects I've developed as a Software Engineer. Also it feels like I built an enterprise tool with how it's deployed in AWS and just the general layout of the application with dashboard views.
Going Forward
For now, I've left the application's projects, tasks, and organizations (orgs) open for others to view. Just to see how the data would work. Eventually I do want to lock this down to the orgs and users that are specified on the project. This would include if I user tried to move a task to a different project, the options would be only to the projects they are a part of.
In this application I had implemented a few ideas of soft deletes, including soft deletes for comments and tasks that can be archived. I would like to consider expanding soft deletes to projects and orgs.
I want to refine some of the views, especially "Hierarchy". The nested tasks made implementing a recursive strategy a challenge to implement on the front-end, specifically the spacing of items (margin and padding). Non inheritance, a whole recursive strategy. I may need to also re-think the grag-n-drop approach here - as the layers can be dropped or drop the task underneath a parent task. The layers can get really wide which makes a challenge to view pleasantly on a screen.
I also had the goal to make this application to be more generalized to more users, rather than just developers. In some ways I feel like it still strays to the development side with some data concepts.
I also like the concept of having task templates where a user could make their tasks look like forms. This could create some better consistency between the tasks in a project. The idea would be to also share templates between projects as well.
I also had the concept of adding attachments early into application development and store them in an S3 bucket. Although I was afraid that if users were uploading a lot of images with unrestrained sizes - it could get costly to manage the application in AWS. To keep things simple and avoid AWS costs, I threw out attachments in the design. Right now, I'm storing the ten images that are referenced in the application in Amplify - this includes the logo and profile photos. With this amount being pretty limited, I didn't think it was necessary to set-up an S3 bucket for this.
A notification system for users could also be a nice feature. When a user is added to an org or a project they could receive a notification. Or maybe the status has updated on a task - a user gets a notification if they authored or created the task. Or expanding on this thought: the user must accept the invite request to join an org.