Recurring Events

[EshaanAgg]

Currently, the API aims to provide support for recurring events so that users can easily make multiple events in a single go. But the same has not been implemented anywhere in our resolvers; thus, currently, the same is just using database space. To proceed with the implementation of the same, there are some common questions that we need to answer:

1. Should we store each instance of a recurring event as a separate field in the database? (This is required as each of these recurring events would have different EventProjects and Assignees)
2. For how long in the future should the same be created for?
3. When should the new event rows be created? How will updates and deletions be managed?
4. What all kinds of recurrences do we want to support? Are just WEEKLY, MONTHLY, and YEARLY type recurrences enough, or do we need to provide support for recurrences of the type Every first Monday of every Month (because just recurrences are very common for many communities).
5. How should we store the recurrence format of the events? The recurrence format should be such that the events are quickly looked up (for calendar views on the client side), and the resolvers can quickly fetch the events between two date ranges without making too many database queries.

Tagging some potential contributors and mentors so that we can discuss the same, and make this part of API functional as it is one of the most critical features that we should be working on if we want Talawa's Event Management capabilities to be actually used by communities and people.
@palisadoes @xoldyckk @kb-0311 @anshgoyalevil @DMills27 @literalEval

[EshaanAgg]

This was one method that I found for the storage of the recurring events, and it provides utmost flexibility, but it has the problem that the same is not very database efficient and relies heavily on the SQL nature of event storage.

[literalEval]

@EshaanAgg seems like a good idea to me.

1. I think we can store the parent event ones and refer to them for each day it will repeat. If we store the event for each day, it will use a lot of unnecessary storage, plus won't work for indefinitely recurring events. Say a user sets an event on every following Monday. How can we store this for each Monday in the future? Doesn't work.
2. Indefinite occurrence should definitely be an option.
   3..5 the SO link you have provided answers very well IMO.

[kb-0311]

@EshaanAgg The articles and forums discussing this use case rely much on the relational heavy nature of SQL. like you said but the same will not work in mongoDB where JOIN operations are a nightmare and multiple DB requests would be very hard on the performance.

We should not store each occurrence a its own event, it will become a nightmare to manage most of us can already visualise that.

For MongoDB, the only data model "flexible " enough I could think of is probably storing the metadata of each occurrence of a recurring event into that event object itself and mapping the timestamp of the event occurrence to the EventProjects and Assignees data that way.

const eventSchema = new Schema({
.... other fields ,

reccurrences_metadata : {[
     occuranceTimeStamp: {  
             type:Date ,
      } ,
    occuranceEventProjects {[
        .... Array of references to Event Projects model
     ]}

    occuranceAttendees {[
        .... Array of references to User model
     ]}

]}
})

This way we can query for timestamps a lot better in the graphql layer by querying for occuranceTImeStamp in the array of reccurrences_metadata and filtering a single occurrence among many occurrences for recurrent events in the DB layer. That also solves the calendar problem.

The updation for each occurrence can be also then customized according to each occurrence with a given timestamp.

However, some extra care would be needed for changing the updation.

I have not thought it through completely though what might the possible pitfalls this approach can fall into?

[EshaanAgg]

Hmm. The foremost problem that I see with this approach is that the embedding of documents is not a scalable approach in the long run. For events that's occur frequently (say weekly, and for indefinite duration), the same would start giving performance issues too soon. Moreover, if we are to store the metadata of recurrence on Events, then we would need to update all the clients to understand and parse that recurrence logic too.

Another idea that I was experimenting with was creating a separate schema called RecurringEvents that will be used to store just the metadata of the events for an organization. Then we can use a scheduler, that would go through this list of RecurringEvents at a fixed frequency (say midnight daily) and would generate an entry for all the RecurringEvents into the Events schema for a fixed duration (say T = 2 years). We can include a reference to the original RecurringEvent object on the generated Event object, so that the same can be used to fetch and group them later, if the need arises.

The biggest advantages of this approach include:

1. All the events can be fetched in a single database query for all the views on the client if the dates requested lie within the time segment T.
2. Having a dedicated Event row for all of them would allow us to continue expanding the API as usual, without having ever to bother about recurrence of the event.
3. Most of the database operations that are intensive in nature can be scheduled to be performed at an off time when the API server is not in use, or the traffic is least, and thus the server would not have to face performance issues.

The only disadvantage that I see that we would have to very carefully think about all the edges cases in the creation, updation and deletion of the events in advance. Designing the scheduler would be a complicated task, but once the same is made, both the clients and all the other models using the Events model in the API would require absolutely 0 change. Any changes that we make to the recurrence model would be strictly isolated to the scheduler and the RecurringEvent model, hence decreasing the coupling of the API and the clients.

What do you think about the same?