ericaddison / Hailing_Frequencies

Final Project for UT Advanced Programming Tools
0 stars 0 forks source link

Firebase Database #24

Open mspagon opened 6 years ago

mspagon commented 6 years ago

Do we already have a Firebase console set up for Hailing Frequencies? @psigourney I am going to create a real-time database instance now if we don't.

I'll invite to give you access and link it to you shortly.

psigourney commented 6 years ago

https://console.firebase.google.com/u/0/project/hailing-frequencies-2017/overview

On Mon, Nov 20, 2017 at 3:04 AM, mspagon notifications@github.com wrote:

Do we already have a Firebase console set up for Hailing Frequencies? @psigourney https://github.com/psigourney I am going to create a real-time database instance now if we don't.

I'll invite to give you access and link it to you shortly.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ericaddison/Hailing_Frequencies/issues/24, or mute the thread https://github.com/notifications/unsubscribe-auth/ACI-NbJMUtuyyJ6PxK5BOD7XWCNleklLks5s4UCogaJpZM4Qj7yg .

mspagon commented 6 years ago

We are going to have to set up the JSON in the firebase console that sets up the database structure and authentication rules:

https://console.firebase.google.com/u/0/project/hailing-frequencies-2017/database/hailing-frequencies-2017/rules

I'm going to get started thinking about it:

Question for @psigourney and @ericaddison: We will need to have conversations, users, messages, etc. stored in Firebase. Should we expand our REST API to handle storing this information in Firebase and NDB simultaneously?

We could have each front-end (web and android) write to the Firebase database and subsequently call the REST API to update the NDB store but this is very clumsy and dirty??

For example, say we are creating a new conversation in the android application. We can have the android application create a new conversation in fire base and then subsequently call the REST API to update the NDB datastore with the same conversation. Ideally the rest api should handle both NDB and firebase?

Structuring data (Web version): https://firebase.google.com/docs/database/web/structure-data Structuring data (REST version): https://firebase.google.com/docs/database/rest/structure-data

mspagon commented 6 years ago

I'm guessing it wouldn't hurt if the Firebase database mirrored the NDB database exactly. And since the REST API has all the data already there, making a single Firebase write alongside the NDB write should be straightforward.

In conclusion, the REST API should just store to the NDB and Firebase simultaneously. Retrospectively, do we even need NDB? Maybe once we have the Firebase going we don't even need NDB?

What do you guys think?

Waiting for input, maybe i'm just confusing myself.

psigourney commented 6 years ago

I was just thinking about the format for the data storage.

I did the "FriendlyChat" tutorial and they were storing chat messages in this format:

[image: Inline image 1]

I was thinking to keep that same hierarchy but add in the conversation ID:

messages => => messageKey => userId/displayName/url/text/etc

On Tue, Nov 21, 2017 at 9:58 AM, mspagon notifications@github.com wrote:

We are going to have to set up the database data JSON https://console.firebase.google.com/u/0/project/hailing-frequencies-2017/database/hailing-frequencies-2017/data and the rules JSON https://console.firebase.google.com/u/0/project/hailing-frequencies-2017/database/hailing-frequencies-2017/rules .

I'm going to get started thinking about it.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/ericaddison/Hailing_Frequencies/issues/24#issuecomment-346071966, or mute the thread https://github.com/notifications/unsubscribe-auth/ACI-NXtDKTpG3QPDn037eGDowphJ1Jarks5s4vMagaJpZM4Qj7yg .