Event Object Discussion

[Caleb-Cohen]

Opening up a discussion to start to tackle the best path forward with the event model.

currently the model takes the form input and creates an array of event objects. The array is then passed back into the front end for viewing. This was done because it connects all the events to one.

What has been proposed is separating the events from an array and have them be their own object with a parent/child connecting the recurring events to the original event.

Would love your thoughts!

[timmyichen]

What has been proposed is separating the events from an array and have them be their own object with a parent/child connecting the recurring events to the original event.

As long as every instance of a recurring event has to exist in a database, you'll always to limit the years in which events can occur, and it makes indefinitely repeating events impossible. Using a schema that does not generate each event instance but is still able to support recurring events will be much harder to implement, but in my opinion is well worth it for several reasons:

1. It's an interesting problem with an interesting solution and may be a fun challenge for the implementer
2. It's the technically "correct" solution in terms of optimization and in terms of what feature sets it would support
3. I've come across this in an interview question and totally bombed it; being exposed to the solution may help collaborators in the future if they come across something similar

Given that, though, it may be worth enumerating all the features you want to support in this app; since each schema design will serve different purposes, and if we don't need X, Y, or Z, more complex designs may not be necessary. Some examples of features might include:

• Create a recurring event indefinitely
• Editing a single event in a recurring series
• Editing a subset of events in a recurring series
• The customization in which you can choose the recurring frequency
• etc / others

Knowing the desired feature first set may help guide us to the design that works best for us.

Feel free to push back on this; I am by no means an expert in calendar schema design and am open to ideas 🙃

[Caleb-Cohen]

Using a schema that does not generate each event instance but is still able to support recurring events will be much harder to implement

Would this require the recurring login to run every time a user accesses the site? If I remember correctly, we decided on building all possible events on the front end and storing them so that the recurring logic would not have to be re-run.

You bring up a good point that we should build this discussion around capabilities before attempting to re-design the schema. I believe these capabilities are essential, but I look forward to others' perspectives.

The Schema

• Does not need to be capable of recurring events indefinitely. Users will come and go in a community, and a way to filter out old and outdated data seems like a good idea.
• Is capable of editing a single event in a recurring series.
• Editing a subset of events seems like a nice to have, but not a must-have. I'm trying to think of an occurrence where I would want to edit more than one event but not all the events, and I'm having a hard time coming up with a hypothetical.
• Capable of handling other recurring frequencies like monthly. Is there use in much more?
• Single recurring events can be editable in date, time, description, and location; they also can be deleted.
• An entire recurring event can be editable in date, time, description, and location; it can also be deleted.

Some future features that we're considering that may also be important for this discussion:

• Users can RSVP for events to be notified (either single events or all events)
• Display total RSVP for a specific event

@intelagense can I get your thoughts on this as well?

[timmyichen]

Using a schema that does not generate each event instance but is still able to support recurring events will be much harder to implement

Would this require the recurring login to run every time a user accesses the site? If I remember correctly, we decided on building all possible events on the front end and storing them so that the recurring logic would not have to be re-run.

It would, but the recurring logic is relatively simple and inexpensive - all it is is just some math, really. Pretty sure this is how google cal does it heh.

Editing a subset of events seems like a nice to have, but not a must-have. I'm trying to think of an occurrence where I would want to edit more than one event but not all the events, and I'm having a hard time coming up with a hypothetical.

I think a realistic scenario is something like an event organizer going "oh hey 2PM on wednesdays doesn't work for me anymore; moving forward future events will take place at 4PM on thursdays" and that would require editing a subset of events.

In any case, I think everything you described can be covered by @miguelbj 's third schema design, which I think is great for this purpose!

[intelagense]

I forgot about the RSVP feature, it is basically a favorite button so we would need a way to tally them and link them back to the User schema. That should also let us add push notifications by linking events to certain users.

Also, if the schema can somewhat mesh with standard calendar apps, we can use APIs to export events to the user's primary calendar.

We need more user feedback to help brainstorm what needs to be added. Maybe we can add a feedback form to the app and implore users to fill it out.

[Caleb-Cohen]

We need more user feedback to help brainstorm what needs to be added. Maybe we can add a feedback form to the app and implore users to fill it out.

That should be a part of the nav discussion on the calendar redesign. Some buttons for "Give us feedback" and "Join the team" links to feedback and Together group thread/github. Would be a good idea.

I'm all for some user feedback regarding this so we do not build useless features. My only concern is that we get caught in an analysis loop instead of committing to event schema changes if we need one.

[guel-codes]

These are some quick initial thoughts:

There should definitely be a threshold set for recurring events so that it can't just make the events forever. Maybe limit it to 12 months out to start.

At first glance it looks like all of the objects in the dates array store the same data as the parent(besides the recurringPattern, recurring and discordName .

I think there are a few options here:

1. Leave it the way it is with an array of dates for all the recurring events.

2. Leave the first/parent event in an event collection and then in a new collection(recurring_events) you can hold the recurring events, which can hold a parent_event__id
   or something to link those events back to the parent.

   • The parent event can hold the info that will not change, like:
     event collection:
     _id
discordName
initialDate
finalDate

     recurring_events collection:
     _id
parent_event_id: This will map to event._id
title:
     description:
     startAt:
endAt:

     For this to work though the first instance of the recurring_events will need to match the intialDate
     title and description can stay in the recurring event object so those can be changed based on the specific _id of that event
     We could leave them in the parent event but then you would have to find the first one on that

     Or...you can do this same model with and event collection and recurring_events collection but the recurring event holds the same data as the parent event:

     event collection:
     _id
title:
     description:
     discordName
initialDate
finalDate

     recurring_events collection:
     _id
parent_event_id: This will map to event._id
title:
     description:
     discordName
startAt:
endAt:

3. [This might be my favorite] Leave them all separate in an event collection:

   • There is not a parent event or child events only a groupId
   • This groupId will let a user make changes to the entire group (CRUD) from the calendar if they confirm that option.
   • If the user deletes one specific event then you would query by that events default _id of that event
   • If a user is editing the title or location for an event on the calendar they can have the option to change that specific event, or they they could change all events

     • You might not want this functionality now but potentially in the future.

         So they all look like
       

       events collection:
       _id
group_id: This will allow for cascade deletions of all events in the chain
       title:
       description:
       discordName
startAt:
endAt:

[Caleb-Cohen]

Miguel the 3 does seem intriguing. What is the drawback or weak points of #3?

[guel-codes]

@Caleb-Cohen off the rope of my head the only downside would be a document for every recurring even but that shouldn't be too bad if you limit the range of events to a set length of time (like 12-24 months).

Depending on how you want to query those events (what field you will use to query) you can add indexes into that specific collection for those fields to help speed up queries.

[intelagense]

I have recently updated the Wiki with a graph of the current event model for visual reference.
04 Architecture

The current schema was adjusted "in place" as the code was developed. The initialDate and finalDate fields are now being used as aggregated metadata and are stored along with most of the other fields to log the initial user input. The entry form output is used to generate the dates of individual events (single or recurring) and the dates array is populated upon form submission.

@timmyichen I think, for 100Devs, the indefinitely recurring events are unnecessary but not including that feature moving forward might be a deal-breaker for other Discords/Slack communities. 🤔

@miguelbj option 2 is sort of what I had in mind while we were building MVP but I also like the idea of option 3 moving forward. We definitely need to have a stronger model in place before the next major release. 💯

[Caleb-Cohen]

I think, for 100Devs, the indefinitely recurring events are unnecessary but not including that feature moving forward might be a deal-breaker for other Discords/Slack communities. 🤔

That's a good point. If I had to choose, I would pick 100Devs over catering to other discords though.

[timmyichen]

@intelagense understood! In which case, I agree that @miguelbj 's option 3 is the best, mostly for its ease of querying. If each recurring event is also an event and has the potential to be an independent event, then it makes sense for that to be reflected in the schema. Having nested events make querying difficult - e.g. instead of just being able to query by ID when making updates, you would have to indicate "is this a nested event", "what is the parents' ID", "which event within the nested list is this", or just query by an ID within both the top-level events as well as nested events - all of which are much more annoying than just treating each event as a first-class citizen.