search

Arquisoft / lomap_en2b

LoMap Software architecture group en2b course 2022_23
https://arquisoft.github.io/lomap_en2b
1 stars 1 forks source link

Selection of Actors #13

Closed andrrsin closed 1 year ago

andrrsin commented 1 year ago

UseCaseASW drawio

In the process of creation of the documentation, I came with the idea of using 4 actors + solid as an auxiliar actor. Being 3 persons and one central system to tighten a bit the centralization while not being a monolith. This diagram can be changed, however this is my proposition.

jjgancfer commented 1 year ago

If I understand this correctly, then we would store everything (minus user data) in the central server by default, right? How about a middle-placed solution between this and not storing anything at all: we could store the same data as proposed, but it is opt-in, meaning there could be cases in which the user's data does not leave their pod at all. It could be harder to implement, though.

andrrsin commented 1 year ago

No, my idea is mostly based on the central system as a gateway between pods. It would only include the data of who follows who. When creating a marker or a route, the request is done to the central system which later stores the created marker or route in the user pod. In the case of reading the data it would be the central system the one in charge of retrieving the data from each of the pods needed.

As a conclusion the central system only stores fixed data such as images seen by every user and the relationship between users.

jjgancfer commented 1 year ago

Then I think the system should be fine that way. Regarding the diagram, I'd specify what user data is; it is a very broad term, after all, and that could lead to misunderstandings (as it already has).

andrrsin commented 1 year ago

Of course user data will be determined in the documentation in its own part. For the moment this is just the business context, explaining who takes part and doing what inside this software.

UO283615 commented 1 year ago

As a conclusion the central system only stores fixed data such as images seen by every user and the relationship between users.

I agree that the centralised DB should store fixed data as images, but I think that the relationship between users could also be stored in each users pod, by storing the ids of the people that follow and are followed by that user. In terms of acceses to each pod for efficiency I think it does not make a difference. For example, if we want to know the landmarks of the friends of a user, we can retrieve the list of friends from his pod and then get the landmarks of each id of the retrieved list doing one pod access per friend and one extra for retrieving the list of friends (n+1 accesses to the pods). If the list of friends is stored in the database we have to retrieve the landmarks of each friend which ends up being n acceses to the pods, being n the number of friends. So if the efficiency is not affected I think we should opt for the SOLID pods as they are more secure.

andrrsin commented 1 year ago

Okay I see what you mean and I totally agree with the proposition. Looks a much wiser approach and yet quite close to my original isdea. Thanks :))

jjgancfer commented 1 year ago

Hmm. I agree that this approach seems more private, but wouldn't storing images in the database create unnecessary overhead in the server? We are not talking about text strings or numbers here, but binary files that can be as large as several MB in the worst cases. If the app will have to be efficient, that is an approach I don't think we should be following.