Backend for managing User IDs

[ainsleys]

This server should store userID, email, and password, and enable users to log-in to their userID in the front-end application. It should also enable the front-end to submit the userID along with other user-submitted data via the SafeTrace API

[cmalfesi]

Hi @ainsleys ,
What architecture we should use here? I think would be good a nodejs + MongoDB working as Rest-API.

Questions:

• It is possible that we use the Google sign-in service or we want to avoid using any external service that identifies the user?
• I think we need to save more data like:
  createDate, agreeToBeNotified, typeOfUser? (reporter vs observer), testResults, testDate
• User can report more that one test results?
• Should save a log of every time that user report or upload positions?

[ainsleys]

Hey @cmalfesi

That architecture seems reasonable to me!

re: questions

1. I think I fall on the side of using google sign-in for the following reasons:

• account recovery is simpler
• bar for security for password management is higher (i.e., account security supports 2fa and authenticator apps)
  But, I would like to consult with @lacabra on the risks of this approach.

2. can you let me know what each of these i.e. what data is expected (just to ensure 100% we're on the same page)?

3. we think yes-- they can report with no test, and then update if they receive a positive or negative yes. Right now the utility isn't 100% clear, but i think makes the app more re-usable and generalizable for different interventions.

4. probably. This can help us reduce spam or load on the system if required. Any reason not to @lacabra ?

Thanks @cmalfesi !

[cankisagun]

@cmalfesi I think a google sign in is OK also happy to do MongoDB + node js

Regarding other data fields:

• createDate (time + date) makes sense
• agreeToBeNotified (0, 1) makes sense
• type of user -> in the future we are planning to add symptoms as well so we may want to create a status for the user like 0 = not tested, no symptons, 1 positive, 2 high risk symptoms (no need to worry about 2 now)
• test date (i.e 3/22/2020) yes. We can either add submission date for all other users

[cmalfesi]

@cankisagun @ainsleys I will create an MVP of this issue during the day, I hope I can have something tomorrow.

[cmalfesi]

FYI: I have forked this project and added a backend subfolder for add the User API endpoints.
I have pushed the first changes. I will be adding more endpoints today.
https://github.com/cmalfesi/SafeTrace/tree/be-express-mongodb-docker/backend

[FishmanL]

Wait, why nosql for this? this seems like a classic case for relationality, maybe postgres?

[ainsleys]

@FishmanL a request for more context in your comment please, many people need to follow this (please note what advantages postgres would confer over current mongoDB solution). We're unlikely to modify anything for the MVP unless the case is really compelling, and afaik mongoDB works fine for this. Appreciate the input & the clarification!

[FishmanL]

Sure -- so, mongo (and similar nosql solutions) are good when you have unstructured data, that you might need to modify within DB, and that doesn't need to scale to lots of users quickly.

In this case, you have very structured data, it's static once posted (all you're doing is adding new rows) and it needs to scale to lots of rows quickly. All 3 of these point to using SQL/a similar structured RDBMS, and with postgres it takes like 3 min to stand up a normalized schema for something like this (user table mapping user info to IDs, location table mapping user IDs to lat,long,time)

[ainsleys]

@FishmanL Just to be really clear, this server is only managing unique userID -> email, password . It should never deal with lat/long/time, that needs to be passed directly from client to the SafeTrace server running code in the TEE.

I'll let @cmalfesi make the call on what approach is sufficient for MVP, but I think we can optimize down the road. At the end of the day, this setup (database + loginAPI + frontend) is all part of the client app, which for our purposes is a prototype that demonstrates the SafeTrace API, so optimization is probably out of scope for the time being. Open to other perspectives, tho.

[FishmanL]

Ah, aight, then it's still best to have it as postgres/another sql install but it's less necessary.

…

On Fri, Apr 3, 2020, 12:22 PM ainsleys ***@***.***> wrote: @FishmanL <https://github.com/FishmanL> Just to be really clear, this server is *only* managing unique userID -> email, password . It should never deal with lat/long/time, that needs to be passed directly from client to the SafeTrace server running code in the TEE. I'll let @cmalfesi <https://github.com/cmalfesi> make the call on what approach is sufficient for MVP, but I think we can optimize down the road. At the end of the day, this setup (database + loginAPI + frontend) is all part of the client app, which for our purposes is a prototype that demonstrates the SafeTrace API, so optimization is probably out of scope for the time being. Open to other perspectives, tho. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#22 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AE32NMED53S2XBCSJHKISGTRKYELBANCNFSM4LVFUKMA> .