Session Notes: 06/19/2024

Change working history to a vertical-scrolling layout. I feel like using a SlideShow would make it hard for people to understand at which stage of your live they are at.
Fill or remove the "References" section on the Wiki.
Wiki / Data Design: add a diagram to the "Overview" section.
Wiki / Data Design / Entities: Is the Persons the correct plural form? Isn't it "people"?
Wiki / Data Design: You seem to have done a "structured design" for a non-structured database. Could you leverage the NoSQL principles/capabilities provided by Mongo? Could you have a sub-collection within "people" for projects & experiences instead of referecing those records using IDs? You should go through MongoDB's docs and understand how their system scales and how their insert/update operations work.
~You have to add support for versioning portfolios.~ Let's start with "Edit" mode.
- As a user, I want to be able to "publish" my portfolio making it available to the public.
- I also want to make changes to my portfolio without publishing them right away. Then, I'll publish those changes and that should become the newest public version of my portfolio.
- I also want to be able to roll back to a previous version of my portfolio.
Add support for signing up/in with Google & Apple.

@hecvasro awesome call outs, thanks a lot!

I have analyzed and will be completing some of the callouts you made here in the next few days. Please see the approach I will be taking below:

I have moved the Wiki to the ReadMe file, it is currently in the feature/chatbot branch, please check it out!
I changed the "persons" collection name to "users" and I will be modifying the objects inside the API to reflect these changes as well.
We could indeed take advantage of some of Mongo NoSql capabilities. However, Mongo does not support sub-collections like CosmosDB does, but they do provide functionality for dividing your collections into shards. This is similar to CosmosDB partitions, where we need to set-up a partition key to create the "shards". I won't be using shards because Mongo does not offer this functionality on their free plan, and I will only be using their free plan for this project. I will however, design the collections in a way that would be easy for me to implement "shards" if I ever upgrade to their pay plans.
I think implementing the "version" capabilities for this project will be interesting. I will need to re-design the collections structures as well as the model objects in the API. I'm already working on this, and I will share the details of my approach in the next comment.

Versioning Functionality

Like I mentioned in the previous comment, adding this versioning functionality will be interesting. I will be creating a new collection and then re-naming the persons collections to be users. On top of that, I will also re-structure the projects, experiences, and achievements collections. Please see the details below:

The users collections will stored user data such as firstName, lastName, dataOfBirth, and emailAddress. It will also have an ID to uniquely identify the user as well as a projectId, achievementId, experienceId, profileId. These ids will be the ids of the current version of each section of the portfolio. This will allow me to ensure I retrieve the appropriate projects, achievements, experiences and profile for the users, it will also allow me to keep a record of previous versions in case the user wants to rollback a section or all sections of their portfolio to a pervious version.
The achievements, projects, and experiences collections will still be separate collections but their schema will be re-structured. Currently, I designed these collections so that projects, experiences and achievements for the same user are created as separate documents within the collection. The new approach will change this, now there will be only one document for a user containing an id column which will be the unique identifier for the version of this section of the portfolio, it will have a userId which is the owner of the portfolio and them an array of sub-documents containing all the users experiences, projects, and achievements. For example: If a user creates a new version of the projects section in their portfolio, then a second document will be created in the portfolio collection with an id of 2, which represents the latest version of this section along with the other columns that have to be present in the projects collection. Now the user has 2 records for projects, one with an id of 1 indicating the first version of the projects section of the user's portfolio, and then another record with an id of 2 representing the latest version of the projects section of the user's portfolio.
The profiles collection will be a new collection which will be design similar to the achievements, projects, and experiences collections. This collection will contain data that are meant to be used in the 'home' section of the portfolio, such as hobbies, shortBio, bio, countryOfBirth, countryOfResidence etc... It will also have an id to uniquely identify the version of the profile as well as a userId to identify to which user this profile belongs to.

Pros

Here are what I considered the pros of these approach:

Separation of concern: by creating different collections which will be storing data related to a specific section of the portfolio. This will also improve retrieval speed since we won't be querying and extracting a single document with a lot of data.
Version control: efficient retrieval will be possible by storing the ids of the current version of the sections of the portfolio in the users collection.
Document-Oriented Schema: Flexible data representation will be possible by using an array of objects within the experience, projects, and achievements collections which fits with MongoDB document-oriented nature.

Cons

Here are what I considered the cons of these approach:

Data Redundancy: We might have duplication of data by creating the versions of the portfolio this way. For example, if a user only changes 1 item in the projects section, then a complete new record with the changes + the untouched values inside the collection will be created again as a separate document. To overcome this, I could try to implement where we only version the changes made to the sections of the portfolio, not the entire section but I think this will lead to complex queries in order to retrieve the data efficiently.

@hecvasro awesome call outs, thanks a lot!

I have analyzed and will be completing some of the callouts you made here in the next few days. Please see the approach I will be taking below:

I have moved the Wiki to the ReadMe file, it is currently in the feature/chatbot branch, please check it out!

I changed the "persons" collection name to "users" and I will be modifying the objects inside the API to reflect these changes as well.

We could indeed take advantage of some of Mongo NoSql capabilities. However, Mongo does not support sub-collections like CosmosDB does, but they do provide functionality for dividing your collections into shards. This is similar to CosmosDB partitions, where we need to set-up a partition key to create the "shards". I won't be using shards because Mongo does not offer this functionality on their free plan, and I will only be using their free plan for this project. I will however, design the collections in a way that would be easy for me to implement "shards" if I ever upgrade to their pay plans.

I think implementing the "version" capabilities for this project will be interesting. I will need to re-design the collections structures as well as the model objects in the API. I'm already working on this, and I will share the details of my approach in the next comment.

Sounds like a plan. Let's make sure to create a "task" issue for each action and let's open separate branches/PRs for the work.

Versioning Functionality

Like I mentioned in the previous comment, adding this versioning functionality will be interesting. I will be creating a new collection and then re-naming the persons collections to be users. On top of that, I will also re-structure the projects, experiences, and achievements collections. Please see the details below:

The users collections will stored user data such as firstName, lastName, dataOfBirth, and emailAddress. It will also have an ID to uniquely identify the user as well as a projectId, achievementId, experienceId, profileId. These ids will be the ids of the current version of each section of the portfolio. This will allow me to ensure I retrieve the appropriate projects, achievements, experiences and profile for the users, it will also allow me to keep a record of previous versions in case the user wants to rollback a section or all sections of their portfolio to a pervious version.

The achievements, projects, and experiences collections will still be separate collections but their schema will be re-structured. Currently, I designed these collections so that projects, experiences and achievements for the same user are created as separate documents within the collection. The new approach will change this, now there will be only one document for a user containing an id column which will be the unique identifier for the version of this section of the portfolio, it will have a userId which is the owner of the portfolio and them an array of sub-documents containing all the users experiences, projects, and achievements. For example: If a user creates a new version of the projects section in their portfolio, then a second document will be created in the portfolio collection with an id of 2, which represents the latest version of this section along with the other columns that have to be present in the projects collection. Now the user has 2 records for projects, one with an id of 1 indicating the first version of the projects section of the user's portfolio, and then another record with an id of 2 representing the latest version of the projects section of the user's portfolio.

The profiles collection will be a new collection which will be design similar to the achievements, projects, and experiences collections. This collection will contain data that are meant to be used in the 'home' section of the portfolio, such as hobbies, shortBio, bio, countryOfBirth, countryOfResidence etc... It will also have an id to uniquely identify the version of the profile as well as a userId to identify to which user this profile belongs to.

Pros

Here are what I considered the pros of these approach:

Separation of concern: by creating different collections which will be storing data related to a specific section of the portfolio. This will also improve retrieval speed since we won't be querying and extracting a single document with a lot of data.

Version control: efficient retrieval will be possible by storing the ids of the current version of the sections of the portfolio in the users collection.

Document-Oriented Schema: Flexible data representation will be possible by using an array of objects within the experience, projects, and achievements collections which fits with MongoDB document-oriented nature.

Cons

Here are what I considered the cons of these approach:

Data Redundancy: We might have duplication of data by creating the versions of the portfolio this way. For example, if a user only changes 1 item in the projects section, then a complete new record with the changes + the untouched values inside the collection will be created again as a separate document. To overcome this, I could try to implement where we only version the changes made to the sections of the portfolio, not the entire section but I think this will lead to complex queries in order to retrieve the data efficiently.

I have a few comments regarding your approach to accomplish versioning.

The achievements, projects, and experiences collections will still be separate collections but their schema will be re-structured.

This approach will definitly work but I think it may add unnecessary complexity.

Have you stop to think about the user-experience around experiences/projects/achievements? Even people with 20, 30, 40 years of professional experience won't add everything to their portfolio. That would make it really hard for other people to read/go through.

As a user, you want to highlight what's important and relevant for the next opportunity you are looking for.

Any thoughts on this?

Ok, based on your questions/comments, I think we could implement then "key" projects, experience & achievements and limit it to a certain amount per user.

But wouldn't still be good to let the user decide what he wants to add to their portfolio instead of limiting them to a certain amount per section of the portfolio?

JGVR / PortfolioApi