Feature Request: Implement GraphQL Query to Fetch Posts by UserID for Profile Page

[Dante291]

Is your feature request related to a problem? Please describe.
Currently, in Talawa-Admin, we can fetch and display posts based on the organization ID. However, for the user profile section in Talawa-Mobile, we need the functionality to display posts created by individual users. The existing system does not support fetching posts filtered by userID.

Describe the solution you'd like
Implement a new GraphQL query named postsByUser (or any suitable name for the query), which takes a userID as an input and returns all posts created by that user. This will allow the user profile section in Talawa-mobile to display user-specific posts, enhancing the profile information with their activity.

Describe alternatives you've considered

Modifying Existing Query: Adjusting the current postsByOrganization query to also filter by userID. This could make the query overly complex and less efficient for its original purpose.

Approach to be followed
1.Update the GraphQL schema to include the postsByUser query.
2.Implement the resolver function for postsByUser, ensuring it queries the database for posts matching the provided userID.

Additional context
This feature is essential for a more personalized user experience in the profile section.

Potential internship candidates
Please read this if you are planning to apply for a Palisadoes Foundation internship PalisadoesFoundation/talawa#359

[github-actions]

Congratulations on making your first Issue! 🎊 If you haven't already, check out our Contributing Guidelines and Issue Reporting Guidelines to ensure that you are following our guidelines for contributing and making issues.

[Suraj-Dhankad2025]

Please assign this issue to me

[1010varun]

Hey @noman2002,
Can you assign this issue to me.

[AdityaRaimec22]

can I get assigned to the issue

[Dante291]

Hey @noman2002, Can you assign this issue to me.

@noman2002 @Cioppolo14 @palisadoes please assign so this could be resolved as this is a prerequisite to the issue I'm assigned to in Talawa-mobile.

[imshivam-gupta]

@Dante291 as an alternative shouldn't we use the PostService to fetch the posts and then filter them on client side to reduce the load on server because when we will start the app the service will be registered after authentication.

[Dante291]

@imshivam-gupta Since posts by a whole organisation is a large data set, Fetching user posts with a dedicated backend query proves more efficient than filtering on the frontend for a few crucial reasons. By tailoring a specific query on the backend, you optimize data retrieval, transmitting only the essential information needed for user posts. This approach significantly reduces the payload sent to the frontend, enhancing overall performance. Additionally, backend filtering leverages the server's processing power, reducing the burden on client devices and ensuring a more responsive and scalable application.

@Dante291 as an alternative shouldn't we use the PostService to fetch the posts and then filter them on client side to reduce the load on server because when we will start the app the service will be registered after authentication.

Yeah this make sense that right when user open Talawa app all posts by the current organisation will be fetched during initialising state but what when user switch between other organisations? PostsByOrg query have to fetch data again and again for different organisations? Having a specific query to fetch all the posts by user is more efficient in Talawa's case.

[Dante291]

@imshivam-gupta Since posts by a whole organisation is a large data set, Fetching user posts with a dedicated backend query proves more efficient than filtering on the frontend for a few crucial reasons. By tailoring a specific query on the backend, you optimize data retrieval, transmitting only the essential information needed for user posts. This approach significantly reduces the payload sent to the frontend, enhancing overall performance. Additionally, backend filtering leverages the server's processing power, reducing the burden on client devices and ensuring a more responsive and scalable application.

@Dante291 as an alternative shouldn't we use the PostService to fetch the posts and then filter them on client side to reduce the load on server because when we will start the app the service will be registered after authentication.

Yeah this make sense that right when user open Talawa app all posts by the current organisation will be fetched at initialising state but what when user switch between other organisations? PostsByOrg query have to fetch data again and again for different organisations? Having a specific query to fetch all the posts by user is more efficient in Talawa's case.

@xoldyckk @palisadoes your views on this?

[imshivam-gupta]

@imshivam-gupta Since posts by a whole organisation is a large data set, Fetching user posts with a dedicated backend query proves more efficient than filtering on the frontend for a few crucial reasons. By tailoring a specific query on the backend, you optimize data retrieval, transmitting only the essential information needed for user posts. This approach significantly reduces the payload sent to the frontend, enhancing overall performance. Additionally, backend filtering leverages the server's processing power, reducing the burden on client devices and ensuring a more responsive and scalable application.

@Dante291 as an alternative shouldn't we use the PostService to fetch the posts and then filter them on client side to reduce the load on server because when we will start the app the service will be registered after authentication.

Yeah this make sense that right when user open Talawa app all posts by the current organisation will be fetched during initialising state but what when user switch between other organisations? PostsByOrg query have to fetch data again and again for different organisations? Having a specific query to fetch all the posts by user is more efficient in Talawa's case.

@Dante291 I think you are right but in future we may require fetching post according to different filters so as an alternative I think we should create a query to fetch the posts and in backend we may use Graphql Filtering to take the leverage of Graphql features otherwise it will be just like a REST API.

[Dante291]

@palisadoes Since user could switch between organizations and make posts in all organizations he joined to, should we be displaying all the posts made by user in all organizations or only the posts made by user in the current selected organization in User Profile section of Talawa App?

and please assign someone for this issue as this issue been hanging for sometime now.

[AdityaRaimec22]

can I get assigned to the issue

@palisadoes can I get assigned to this issue.

[xoldd]

@imshivam-gupta Since posts by a whole organisation is a large data set, Fetching user posts with a dedicated backend query proves more efficient than filtering on the frontend for a few crucial reasons. By tailoring a specific query on the backend, you optimize data retrieval, transmitting only the essential information needed for user posts. This approach significantly reduces the payload sent to the frontend, enhancing overall performance. Additionally, backend filtering leverages the server's processing power, reducing the burden on client devices and ensuring a more responsive and scalable application.

@Dante291 as an alternative shouldn't we use the PostService to fetch the posts and then filter them on client side to reduce the load on server because when we will start the app the service will be registered after authentication.

Yeah this make sense that right when user open Talawa app all posts by the current organisation will be fetched at initialising state but what when user switch between other organisations? PostsByOrg query have to fetch data again and again for different organisations? Having a specific query to fetch all the posts by user is more efficient in Talawa's case.

@xoldyckk @palisadoes your views on this?

this is a standard data fetching practice, I wouldn't approve any new PRs that filter/sort potentially large amount of data on the client side, this is a job for the server not the client

though talawa-api already has some places where this is done client side, but that is legacy technical debt, to fix that much of the client side code has to be fixed as well because clients currently don't make use of graphql connections(cursor pagination technique) to fetch small spurts of data one by one

also instead of Query.postsByUser it should be User.posts or User.postsConnection, a resolver that abstracts the user.id <-> post.creator_id foreign key relation and presents the posts created by that user as a field directly on the User type

[github-actions]

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.

[Cioppolo14]

Unassigning due to no activity.

[AVtheking]

I would like to work on this issue

[github-actions]

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.

[github-actions]

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.