Add pagination support to EventsByOrganization query

[Azad99-9]

Is your feature request related to a problem? Please describe. Currently the EventsByOrganization query fetches all event entries at once. The number of event entries in the database has drastically increased after adding the Recurring events feature. This has resulted in slow API fetching times.

Describe the solution you'd like Implement pagination for EventsByOrganization. This will allow fetching events in smaller, manageable sets based on user needs (e.g., number of events per page).

Describe alternatives you've considered A clear and concise description of any alternative solutions or features you've considered.

Approach to be followed (optional) A clear and concise description of approach to be followed.

Additional context Add any other context or screenshots about the feature request here.

Potential internship candidates Please read this if you are planning to apply for a Palisadoes Foundation internship https://github.com/PalisadoesFoundation/talawa/issues/359

[palisadoes]

@aashimawadhwa @rishav-jha-mech @DMills27 PTAL and comment

[palisadoes]

@xoldd This was discussed frequently in the past, however related to news feeds. PTAL too

[palisadoes]

@Azad99-9 @meetulr Do you think this can be implemented without the UI/UX functionality being affected for both Admin and Mobile?

[Azad99-9]

@palisadoes For the mobile part the UI should be tweaked to accomodate the pagination.

[meetulr]

Both the admin and mobile will need to be updated simultaneously according to the changes in the API. We'll need contributors for both. Would depend on how the query is modified in the backend. A proper approach should be established first.

[palisadoes]

1. That's what I figured. We don't want to break the apps.
2. Will we need to modify the newsfeed and its infinite scrolling?

[xoldd]

Would depend on how the query is modified in the backend. A proper approach should be established first.

I've documented the standard approach to be followed throughout talawa-api for implementing pagination using the graphql connections:- https://docs.talawa.io/docs/developers/talawa-api/pagination

Implement pagination for EventsByOrganization

Again, REST like patterns should not to be followed with graphql, relationships and fetching patterns should be expressed in the graph. This is an anti-pattern:-

type Query {
  eventsByOrganization(organizationID: ID!): EventsConnection
}

The events associated to an organization should be exposed like this:-

type Organization {
  events: EventsConnection
}

On the client side querying for the events within an organization would look like this:-

type OrganizationEventsQuery($cursor: String, $limit: Int!, $organizationID: ID!) {
  organization(id: $organizationID) {
    address
    phoneNumber
    events(first: $limit, after: $cursor) {
      edges {
        cursor
        node {
          id
          ...other event fields
        }
      }
      pageInfo {
      ... fields
      }
    }
  }
  name
}

The advantage here is that you can fetch other fields like address, phoneNumber, name etc., that exist on the organization along with the events associated to that organization. This is more efficient because the client only sends 1 network request to fetch everything that is needed. The server takes care of resolving everything listed in the query.

When the next set of events are to be fetched(connection is to be traversed further) a new network request would be made with a non-null value for the $cursor variable. This time there's no need to fetch the organization fields like address, phoneNumber, name etc., because they were already fetched by the very first network request. This would look like this:-

type OrganizationEventsQuery($cursor: String, $limit: Int!, $organizationID: ID!) {
  organization(id: $organizationID) {
    events(first: $limit, after: $cursor) {
      edges {
        cursor
        node {
          id
          ...other event fields
        }
      }
      pageInfo {
      ... fields
      }
    }
  }
}

To understand how the client implementation would work, take a read:-

1. https://www.apollographql.com/docs/react/pagination/overview
2. https://www.apollographql.com/docs/react/pagination/core-api
3. https://www.apollographql.com/docs/react/pagination/cursor-based#relay-style-cursor-pagination
4. https://commerce.nearform.com/open-source/urql/docs/basics/ui-patterns/#infinite-scrolling
5. https://commerce.nearform.com/open-source/urql/docs/graphcache/local-resolvers/#pagination

[Azad99-9]

When the next set of events are to be fetched(connection is to be traversed further) a new network request would be made with a non-null value for the $cursor variable. This time there's no need to fetch the organization fields like address, phoneNumber, name etc., because they were already fetched by the very first network request. This would look like this:-

Yes we already use a similar approach in organizationsConnection query.

[palisadoes]

@Azad99-9 Are you working on this?

[Azad99-9]

@palisadoes I am not working on this. But this needs to be addressed. To resolve client side performance issues.

[xoldd]

Should I do it?

[Azad99-9]

Yes kindly do it. Thanks.

[Maniii97]

hey, is this issue up? can i be assigned to do this?.

[Cioppolo14]

@Maniii97 Thank you for your interest. Please keep looking, as I'm sure we have open issues and we'd love your help. If any issue is already assigned, please don't ask to be assigned. We want everyone to get a chance.

[github-actions[bot]]

This issue did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please check if the develop branch has fixed it and report again or close the issue.

[AnshulKahar2729]

Please assign me this issue, I would like to work on this.

[Cioppolo14]

@xoldd Are you working on this?

[xoldd]

@xoldd Are you working on this?

I had made a PR that incorporated the required changes but it was failing the prettier formatting test which I wasn't able to fix on my local system. So, Peter closed the PR. I'm currently not working on this anymore so you can assign it to @AnshulKahar2729.

@AnshulKahar2729 You can reference my PR and make a similar PR.

[AnshulKahar2729]

@xoldd Are you working on this?

I had made a PR that incorporated the required changes but it was failing the prettier formatting test which I wasn't able to fix on my local system. So, Peter closed the PR. I'm currently not working on this anymore so you can assign it to @AnshulKahar2729.

@AnshulKahar2729 You can reference my PR and make a similar PR.

Ok I will do that

[AnshulKahar2729]

@xoldd Are you working on this?

I had made a PR that incorporated the required changes but it was failing the prettier formatting test which I wasn't able to fix on my local system. So, Peter closed the PR. I'm currently not working on this anymore so you can assign it to @AnshulKahar2729.

@AnshulKahar2729 You can reference my PR and make a similar PR.

Ok I will do that

Working on this... Will soon raise a PR.

[github-actions[bot]]

This issue did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please check if the develop branch has fixed it and report again or close the issue.

[AnshulKahar2729]

This issue did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please check if the develop branch has fixed it and report again or close the issue.

Working....

[github-actions[bot]]

This issue did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please check if the develop branch has fixed it and report again or close the issue.

[AnshulKahar2729]

working

[github-actions[bot]]

This issue did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please check if the develop branch has fixed it and report again or close the issue.

[AnshulKahar2729]

This issue did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please check if the develop branch has fixed it and report again or close the issue.

Working on this... I am just solving another issue too.

[palisadoes]

Unassigning. Inactivity

[zakhaev26]

can i work on this issue? @palisadoes currently learning the tools and exploring talawa softwares. this would help me learn more!

[github-actions[bot]]

This issue did not get any activity in the past 10 days and will be closed in 180 days if no update occurs. Please check if the develop branch has fixed it and report again or close the issue.

[palisadoes]

unassigning. inactivity

[prashantrai-30]

Hey @palisadoes, I would like to on this. Can you assign this to me :)

[VijeshVS]

Hi @palisadoes, I’d like to take on this issue and implement the suggested pagination for the EventsByOrganization query.

Proposed Steps: Fetch event entries batch-wise to improve API performance and reduce loading times. Display events with pagination to manage and navigate entries more effectively.

Thank you!

[palisadoes]

During the week of November 11, 2024 we will start a code freeze on the develop branches in Talawa, Talawa Admin and Talawa-API.

We have completed a project to convert the Talawa-API backend to use PostgreSQL. Work will then begin with us merging code in the develop branches to a new develop-postrgres branch in each repository.

Planning activities for this will be managed in our #talawa-projects slack channel. A GitHub project will be created to track specially labeled issues. We completed a similar exercise last year using a similar methodology.

Starting November 12, California time no new PRs will be accepted against the develop branch. They must be applied to the develop-postrgres branch.

There are some GSoC project features that will need to be merged into develop. These will be the only exceptions.

This activity and the post GSoC 2024 start date was announced in our #general Slack channel last month as a pinned post.