-
Notifications
You must be signed in to change notification settings - Fork 2
Risks
Below are listed potential risks that can come during the development of the project. Some solutions are mentionned, but these need to be assessed in depth.
Building an authentication system allowing EPFL-only users will come with several obstacles. There are three auth providers that could be used, namely Tequila, Google, or Microsoft.
Tequila and Microsoft may not allow authentication requests from foreign applications. This leads to using Google, but doing that would prevent accessing metadata about the profile (e.g. joined associations etc.). However the metadata can still be manually fetched from search-api.epfl.ch/api/ldap.
Using Google also adds an additional layer of verification to the account creation, to check for epfl.ch emails. Using Firebase Cloud Functions to create accounts may be a solution to that issue.
As the project evolves, the team needs to clearly define any modification made from the design planned initially, review it with other team members and modify the Figma in accordance to the new design. A protocol needs to be put in place, otherwise the project could suffer a global lack of coherence.
To model relationships between Users and Associations, a typical representation would be using join tables in an SQL database. However, Firebase Firestore doesn't natively support this, so another solution must be found. Two main factors need to be considered before implementations; performance vs SSOT.
The approach that would have the best performance is the following:
- Users have a
users/{userId}/followingAssociations/collection containing documents about each association they follow. - Associations have a
associations/{associationId}/followers/collection containing documents about each of their followers.
The downside to this approach is that the database has several sources of truth, that may conflict if write requests are not correctly sent.
In order to keep a single source of truth, the following database architecture is suitable:
- There exists a
followings/${followingId}collection that contains documents with theuserIdand theassociationIdof the follow relationship.
While this prevents data-duplication, querying the collection will become slower and slower as new follow relationships are created. A hybrid approach may be needed for the project.