Description:
The leader information of beacons is currently returning null when querying group details. This affects the accuracy of beacon details.

Steps to Reproduce:

Query group details.
Check leader field within Beacon objects.
Observe null values instead of expected leader details.

Expected Behavior:
leader field in Beacon objects should contain the respective user details in group queries.

Currently, the codebase is a bit unstructured, with all the errors, mutations, and queries in the same resolver file.

Solution proposed:
A well-defined architecture could be introduced, with rebased mutations and queries for different functionalities to be separated in different files with their respective usage and used individually and for a more readable codebase.

This issue (open for discussion!) describes the detailed implementation on how to update the backend for this feature.

Current roadmap (in-order):

• Implement data model: Group data model should be added to be able to store it in MongoDB.

GroupModel = {  
	id, 
	shortcode //(can be used to join), 
	title //name, 
	[followers id] //list, 
	leader id //super leader (who created the group, with ability to delete the grp (TBD), 
	[beacon ids] //list.
}

• Update existing models,
  • Beacon model:
    • New field, grpID = id of the group belongs to.
    • Remove the followers list, since it is same as group's followers list. (TBD)
    • Remove shortcode, since joining the group is sufficient for joining the beacon. (TBD)
    • leader is not same as the group’s leader. Here leader is the one who created it, which can later be changed using changeLeader() mutation.
  • User Model:
    • New field, groups = [ids of all the groups the user is a part of].
• New mutations for creating, joining and fetching a group (changes to be done is resolvers and typedefs).
  • createAGroup() , fairly straightforward, creating a new group with all the fields and saving it in the DB.
  • joinAGroup(shortcode), Add the new member to all the beacons in the group, also use pubsub to publish this change.
  • getGroupDetails() (small thing to be taken care of is populating the necessary fields before returning).
  • nearby groups, what is a “group’s location”? (TBD).
• Update the existing mutations, queries and subscriptions to incorporate group model.
  • Update me query.
  • Update createBeacon() and joinBeacon() mutations.
  • Change beaconJoined() subscription to groupJoined(), since the followers list is same for all the beacons in the group.

(TBD = To be discussed)

There is no mutation to delete a beacon on leader's demands. Any beacon created gets stored forever. A mutation for deletion could be introduced.

Currently, once a beacon is created it cannot be deactivated but to implement the deactivation feature (in frontend ) we need this mutation.

This will allow us to solve CCExtractor/beacon#5

There's no subscription to check whether a user is online. This could be helpful in checking if a user can be made the leader or not as in CCExtractor/beacon#4.

There is no mutation to change the start time of a beacon. A new mutation for editing start time could be introduced.

Right now users can join more than one hikes at the same time which should not be allowed.

There is currently no way to recover one's forgotten password or create a new one for registered users.

Upon querying the beacon for the leader's name under nearby beacons, we get a null value which results in the leader being shown as anonymous on the app.

Upon terminating the hike and coming back to the home screen, my own beacon is shown as Anonymous. This is because nearbyBeacons query in the backend gives out null as the leader's name.

This would help in fixing issue CCExtractor/beacon/issues/35

I mean will this sync the updates for all and stop the subscriptions if beacon has been deactivated?
Originally posted by @nb9960 in CCExtractor/beacon#97 (comment)

As the beacon is subject to lot of changes, having multiple subscriptions can be inefficient. To allow users to subscribe to beacon updates(modifying leader, start/end time etc) and location updates(all users of the beacon), a single stream can be used to achieve this. This will require to change the beacon model.

This issue is open to further discussion, to choose the best way to implement it.

Are yo working on it?
Yes

There's no mutation to end a beacon upon the leader's termination of the hike. The beacon remains active even after the leader terminates it.

As originally posted by @nb9960 in CCExtractor/beacon#5 (comment)

Description:

Currently, the beacons do not load in real-time, impacting the user experience. To address this, we need to implement improvements that ensure instantaneous loading of beacons for a smoother interaction.

User should not be able to join the beacon he is already part of (i.e., either he is a leader or follower). As all the beacons he is a part of are displayed under your beacons and can be navigated from there.
Secondly, when the beacon's details are fetched using query beacon(...) leader's name is returned as null, because of which Anonymous is getting displayed.

Originally posted by @nb9960 in CCExtractor/beacon#48 (comment)

There seems to be no server for hosting queries or subscriptions for the app. The link to GraphQL playground shows an error.
This causes the app to be unable to do the required tasks. @aadibajpai Is this problem noticed by you already?

i have joined a group with code. on clicking group beacons don't show up with error message in terminal as user shoup be part of group.

Please assign me this issue.

Front end issue - CCExtractor/beacon#160
Currently, the app only accepts email sign in/signup. Having oauth would be better for the user, then user can sign in with ease.
Also there is PR for email verification, having oauth wont even need email verification. (Although that feature would be required for user sign in with their email).

Some error messages being thrown do not represent the particular type of error they are pointing to. We could change some wordings to make them better!

Currently, once a beacon is created we cant change is duration, to implement this (in frontend) we need a mutation to change the duration (expiresAt param of beacon).

This would allow us to solve CCExtractor/beacon#17.

Thanks.

Should the last(5th) be part of backend logic or frontend?

Anything related to security / privacy / etc must be handled in the backend - you just can't trust the frontend :-)

So the backend should prevent joining an expired beacon, return some error, and then the frontend can capture that error and display it.

Originally posted by @cfsmp3 in CCExtractor/beacon#33 (comment)