SCCapstone / Delta

A file transfer system for researchers to upload and share data sets with other researchers.
0 stars 0 forks source link

What is your deployment architecture? #21

Closed josemvidal closed 2 years ago

josemvidal commented 2 years ago

From your weekly report and project description, it seems like you are working on an Android kotlin app, a django webapp, and firebase, and there is a 3rd party AI model. 😨 !

Typically, we have just an Anroid app+firebase. What is the plan for putting all these together?

Something like this?

flowchart LR
    A[<em>phone</em><br/>kotlin app]<-- JSON -->B[<em>server</em><br>django REST framework]
    A <-- JSON -->D[firebase]
    B <-- ??? -->E[AI Model]
    classDef box fill:#fff,stroke:#000,stroke-width:1px,color:#000;
    class A,B,C,D,E box
lxaw commented 2 years ago

@josemvidal Yes, this is the plan. As I did not explain it well, I will add to the description of the project. In reality Dr. Valafar just wants us to do the Kotlin <-> server aspect, and he has hired others to do the AI Model. He mentioned not to worry about Firebase, but I may look into it regardless as I think that it could be helpful. The drawing above is very similar to our implementation idea.

Essentially we are developing something that can easily transfer data between phone / server, and will be in correspondence to see how the other team he has for the AI model wants to use that data. We are just making the platform.

Thus our part is more about Android Watch <-> Android Phone <-> Server, focusing primarily on the transfer of data. The AI model will be done by others. I have met with my team to explain this online, but I will write something up to better explain.

josemvidal commented 2 years ago

There is a watch? I did not see that. As I understand it, WearOS is different from Android. You would need to build 2 apps: wearos and android.

Looks like wearos can talk to the network directly. So, the watch could talk to the server directly, or to the phone app (the Wearable Data Layer API). That is the decision you will have to make.

You can just "mock" the 3rd party API. That is, pretend you are calling it, but the function you implement just returns True (or, whatever you need) every time you call it. Since the AI model is not your code, it does not matter for this class, so you can just pretend it exists.

lxaw commented 2 years ago

@josemvidal The watch aspect is a part another group is developing; we have been in contact with them about this matter. Thank you for the WearOS link, that will likely prove useful. Also thanks for the pointer on the 3rd party API, this too is useful.

josemvidal commented 2 years ago

From what I've read, if you have the phone app talking directly to the watch then your team will need to write both of those apps as the code is heavily integrated.

But, if the watch talks to a server, and the phone talks to the same server, then the phone-app and watch app are completely independent. So, you can write either one separatedly.

lxaw commented 2 years ago

@josemvidal Yes, the plan as of yet is to communicate mainly only through the server to keep dependencies down.