Coding

How to Structure Firebase (NoSQL) Data | Firebase with Abe (Google Developer)

  • 00:00:05 so in this video you walk through
  • 00:00:09 firebase in general and we look at all
  • 00:00:11 these features or the most important
  • 00:00:12 features when it comes to building your
  • 00:00:13 app and when the super important 52
  • 00:00:16 feature obviously the database what we
  • 00:00:17 what can store our data read it and so
  • 00:00:19 on and when we talk about the database
  • 00:00:22 we got like a basic structure here for
  • 00:00:25 example from the app we saw in the
  • 00:00:26 previous video where we could push our
  • 00:00:28 messages into the database and then it
  • 00:00:30 words because I had this as a reference
  • 00:00:32 here when we pushed it I reference
  • 00:00:35 messages they would create this messages
  • 00:00:38 note and simply add all these messages
  • 00:00:41 with these IDs right and that's a super
  • 00:00:42 simple structure obviously so here if we
  • 00:00:46 withdraw this is one example structure
  • 00:00:48 basically we have like the key messages
  • 00:00:51 here and then obviously our different
  • 00:00:53 IDs which are a cryptic strings like
  • 00:00:56 like this one below that s messages now
  • 00:01:01 the thing is since you can structured
  • 00:01:03 like Jason there is the ideal or the
  • 00:01:05 danger that we create super deeply
  • 00:01:07 nested structures especially if we would
  • 00:01:09 imagine we had not just messages but we
  • 00:01:11 had different rooms and maybe a message
  • 00:01:13 could be part of separate rooms then you
  • 00:01:16 could get a much more complicated
  • 00:01:17 structure so what are some common
  • 00:01:19 pitfalls or English to wait yeah well I
  • 00:01:22 think the biggest thing when you're
  • 00:01:23 thinking about building a data structure
  • 00:01:25 in firebase is you have to think about
  • 00:01:28 how is your data going to be consumed so
  • 00:01:31 pitfalls and issues come from not really
  • 00:01:34 general rules as much as how are you
  • 00:01:37 going to consume this it in your app and
  • 00:01:39 there's issues there so like this
  • 00:01:41 messages is great right now if we're
  • 00:01:44 only dealing with you know a list of
  • 00:01:46 text where each users or Samsung's you
  • 00:01:48 know this is Texas is a message and just
  • 00:01:50 stacks up if you need to add complexity
  • 00:01:52 that you have to start thinking about
  • 00:01:54 how am I going to use this data so an
  • 00:01:56 example would be if each message
  • 00:01:58 headaches under yeah so I send a message
  • 00:02:00 and it shows like my profile image or my
  • 00:02:04 name next to it and the immediate
  • 00:02:07 question with firebase is do you just
  • 00:02:09 tack that under here I can show you so
  • 00:02:12 would you just tack that under
  • 00:02:14 this these kinds that I got under this
  • 00:02:16 will have a name and like a photo URL so
  • 00:02:20 that would be completely fine in a lot
  • 00:02:24 of situations there's nothing inherently
  • 00:02:25 wrong with that we have huge chats that
  • 00:02:27 just have this but you can imagine a
  • 00:02:29 situation where I'm a user maybe I
  • 00:02:31 changed my profile photo now every
  • 00:02:34 single message I've ever sent is going
  • 00:02:35 to have that old photo URL so this is a
  • 00:02:39 case where it becomes the veteran call
  • 00:02:40 what do you want to do do you want to
  • 00:02:42 store this name in this photo under each
  • 00:02:45 message or do you want to store
  • 00:02:46 alternatively if it's another crazy idea
  • 00:02:49 under that just their UID
  • 00:02:52 and then look up that data yeah and both
  • 00:02:55 of these are reasonable the UID one
  • 00:02:57 works better if you have fewer people in
  • 00:02:59 the chat if it's a conversation between
  • 00:03:00 me and you that's only two UID so if
  • 00:03:03 it's a twitch chat and you have a
  • 00:03:05 hundred thousand people talking in it
  • 00:03:06 probably makes more sense to this it's
  • 00:03:08 not only are those messages more shortly
  • 00:03:10 lived but they have a lot more people so
  • 00:03:13 to be more trips to pull out all the
  • 00:03:15 data from the profile so each one can
  • 00:03:18 work it just depends on how you're using
  • 00:03:20 it and this is the general thing like
  • 00:03:22 firebases how am i consuming the data
  • 00:03:24 and structuring in a way that it makes
  • 00:03:26 sense when you want to pull it back yes
  • 00:03:28 and you can maybe do like a
  • 00:03:29 Hossler that you store the name and the
  • 00:03:32 ideas of you have to name right away let
  • 00:03:34 us display that next to the message also
  • 00:03:36 have the ID if you need to reach out and
  • 00:03:38 pull them extra just formation they
  • 00:03:40 click on a message and you can
  • 00:03:42 definitely do that and something like
  • 00:03:43 that is a great case where profile
  • 00:03:45 photos tend to take a second to learn
  • 00:03:48 anyway so an extra extra round trip that
  • 00:03:50 only takes as long as they fire bit.trip
  • 00:03:52 text that we sell is it not long threw
  • 00:03:54 that on top of the normal image loading
  • 00:03:56 is probably noticeable yeah so that's a
  • 00:03:58 completely reasonable route and that's
  • 00:03:59 why these priorities of what data should
  • 00:04:01 I sir where what you're like copy or
  • 00:04:03 denormalized comes down to what you care
  • 00:04:06 about in your app mm-hmm that makes a
  • 00:04:08 lot of sense and I think when I don't
  • 00:04:10 think which is important to keep in mind
  • 00:04:12 is if you have very complex structures
  • 00:04:14 with a lot of nesting you fetch all the
  • 00:04:16 data every time you you basically
  • 00:04:18 queries or you have this on listener and
  • 00:04:21 you get all the data and it's just what
  • 00:04:22 I get all the messages you get
  • 00:04:24 everything which is nested below that
  • 00:04:25 you write exact
  • 00:04:26 and this is one of the general themes
  • 00:04:28 with firebase is that if you're loading
  • 00:04:30 one thing you're loading all of its
  • 00:04:32 siblings as well so an example of that
  • 00:04:35 is if I wanted to load it if I loaded a
  • 00:04:37 /t messages I would get all of the
  • 00:04:41 children yeah I wouldn't generally get
  • 00:04:43 this one and this first record and the
  • 00:04:46 second record and no other records you
  • 00:04:49 could do that you could pluck those
  • 00:04:50 throughout if you really wanted to but
  • 00:04:52 that's not really how its set up so
  • 00:04:54 you're not only loading you know the
  • 00:04:56 entire list of messages but like you're
  • 00:04:57 send you're loading everything under
  • 00:04:59 every single one so you can limit those
  • 00:05:01 you can say let me give you ten messages
  • 00:05:02 into the last ten give me the ones that
  • 00:05:04 have this exact field or tag or
  • 00:05:06 something on them so there are you know
  • 00:05:08 extra things you can do that but in
  • 00:05:10 general you have to realize that when
  • 00:05:12 you're loading data you're loading all
  • 00:05:14 of it they're not fields or
  • 00:05:16 things like that that makes a lot of
  • 00:05:17 sense so if you are coming from maybe a
  • 00:05:20 sequel background you you have like
  • 00:05:23 obviously a lot of tables and connect
  • 00:05:25 them by ID typically and as you already
  • 00:05:28 mentioned kind of you can store the UID
  • 00:05:30 here too to basically rebuild this when
  • 00:05:33 it's needed or when it makes sense but
  • 00:05:35 it's also important to take advantage of
  • 00:05:37 this like MongoDB like structural DD
  • 00:05:40 Jason structural item – yeah as it says
  • 00:05:42 make a judgment call next what makes
  • 00:05:44 sense to next and and that's the thing
  • 00:05:46 storage is key right like I can copy a
  • 00:05:49 name a hundred thousand times and it
  • 00:05:51 will cost me functionally nothing it's
  • 00:05:53 extremely extremely cheap to do but what
  • 00:05:56 is more expensive is loading that onto
  • 00:05:58 the client how many times am I going to
  • 00:06:00 pull down that setting name things like
  • 00:06:02 this do come to concern but in general
  • 00:06:04 like storing the same the same thing a
  • 00:06:07 bunch of times is very cheap
  • 00:06:09 yeah and it's a lot more expensive to
  • 00:06:10 pull things down on the client do
  • 00:06:12 complicated connections and transform
  • 00:06:13 it's generally easier to just write the
  • 00:06:16 same data again because it's just
  • 00:06:17 probably you can get an easy change but
  • 00:06:19 in because you do have to change it like
  • 00:06:21 you can use either construction but yeah
  • 00:06:24 it works really well to do like named
  • 00:06:26 photo of time of the time yeah that
  • 00:06:28 makes a lot of sense um how would you
  • 00:06:31 adjust to have a doubler example how
  • 00:06:32 would you example awfully structure it
  • 00:06:35 if you had like chat rooms with messages
  • 00:06:38 in there and then we also have users
  • 00:06:39 human most excel for deadly yeah so if
  • 00:06:42 you're having like I use your profile
  • 00:06:43 you're talking about it yeah so provoke
  • 00:06:46 we probably want to set this up so we
  • 00:06:48 have a high level two they're not really
  • 00:06:52 tables but two collections of a type of
  • 00:06:55 thing so example that when we would have
  • 00:06:57 like rooms up here and under that we
  • 00:07:00 would have room IDs and those would be
  • 00:07:02 those crazy ABCs and then under that
  • 00:07:05 will have all the messages for that room
  • 00:07:08 but we wouldn't want to store them just
  • 00:07:10 like this where it's you know exactly
  • 00:07:12 under the unique key we want to do
  • 00:07:14 something where we have probably
  • 00:07:16 messages under that and then under
  • 00:07:20 messages will put in each individual ID
  • 00:07:22 as they come in an agent critical
  • 00:07:24 message that'll yell hi whatever
  • 00:07:26 oh and so by doing this we give us a
  • 00:07:30 little bit more flexibility because this
  • 00:07:32 room has that unique ID that's not a
  • 00:07:34 human readable name that's not anything
  • 00:07:35 interesting so we could also have next
  • 00:07:38 to messages we could have like title in
  • 00:07:40 title could be you know the name of that
  • 00:07:43 chat or the name of that room so if I
  • 00:07:46 come by later I can load at this level
  • 00:07:49 I'm inside room slash ABC and I will get
  • 00:07:51 back all the messages on the title along
  • 00:07:54 with any other metadata or anything else
  • 00:07:56 interesting I put down here in the
  • 00:07:58 future I can come along I'll use that I
  • 00:07:59 I really only want that room title so I
  • 00:08:02 can go rooms this ABC key and just the
  • 00:08:05 title and just get that but most of the
  • 00:08:08 time I'm going to be loading all this
  • 00:08:09 data as it's one group now if we have
  • 00:08:12 another structure like users that you're
  • 00:08:14 talking about user profiles or your
  • 00:08:16 photos and your L things like that we
  • 00:08:18 could have another top-level collection
  • 00:08:20 just called like users and under that
  • 00:08:23 instead of using crazy unique IDs we
  • 00:08:25 would use their u ID as the key so now
  • 00:08:30 when a user signs in or when a UID is
  • 00:08:33 referenced by a message we know we can
  • 00:08:35 look at users slash their unique ID and
  • 00:08:38 under that will be you know their name
  • 00:08:41 Co file image everything like that and
  • 00:08:44 this is the second big thing about
  • 00:08:45 structuring firebase data is that you're
  • 00:08:47 not only building for how you're
  • 00:08:50 consuming it but you're building your
  • 00:08:51 structure in a way
  • 00:08:52 you know where to look it which is a
  • 00:08:55 really interesting concept to me because
  • 00:08:56 the idea that your data is getting
  • 00:08:59 pushed into an array it's basically lost
  • 00:09:01 you don't know where it is you don't
  • 00:09:03 know what key is associated with it but
  • 00:09:04 you can if you're building up this path
  • 00:09:07 you know that any UID you have if you
  • 00:09:09 look at user slash that you already
  • 00:09:11 slash the name that would be that
  • 00:09:13 person's name yes and so it's reliable
  • 00:09:15 so you don't even have to load data from
  • 00:09:16 the server you can just say I know where
  • 00:09:18 to look to pull this out and render in
  • 00:09:20 mind that that's really interesting and
  • 00:09:22 we guess that you are a Z from basically
  • 00:09:25 firebase again if we use alt education
  • 00:09:27 we get to back and we create a user and
  • 00:09:29 then this may be important we have to do
  • 00:09:31 that part on our own but we need to push
  • 00:09:33 the data to do real-time database you
  • 00:09:35 can't leverage the firebase of Education
  • 00:09:37 we can't store it the same databases
  • 00:09:39 email password yeah no they're
  • 00:09:40 completely separate because like email
  • 00:09:42 password we don't want you to possibly
  • 00:09:43 exposed yes or a shits right so they're
  • 00:09:45 complete completely separate but there's
  • 00:09:47 absolutely no reason you can't use a
  • 00:09:49 yellow ID like this or even uses
  • 00:09:51 somewhere else so you can imagine a
  • 00:09:53 situation where users head rooms like I
  • 00:09:55 as a user have my own list of
  • 00:09:57 conversations so you could put another
  • 00:09:59 node in here we go rooms and then under
  • 00:10:01 that like in between here put their UID
  • 00:10:03 and then under each UID you have a list
  • 00:10:06 of my own conversation things like that
  • 00:10:09 you have you have a ton of options for
  • 00:10:11 how to do that and that UID is a really
  • 00:10:13 powerful concept for just storing data
  • 00:10:15 for your user is very commonly used as
  • 00:10:19 as an identity and like I was talking
  • 00:10:20 about before you can rely on that even
  • 00:10:22 if you're using anonymous off or you're
  • 00:10:24 using phone or email password you always
  • 00:10:26 have those UID to say this is the user
  • 00:10:27 I'm going to store it knowing that
  • 00:10:29 they're you ideas associated with them
  • 00:10:31 now what I know is that it can be
  • 00:10:33 difficult to you to make that judgment
  • 00:10:35 call you mentioned so cute you guessed
  • 00:10:37 that right set up and are there some
  • 00:10:40 ways we could think about it or some
  • 00:10:43 some tips you could give so how to make
  • 00:10:45 this decision they're obvious it's never
  • 00:10:46 that clear right or wrong but some ideas
  • 00:10:49 or how do you approach this yeah so my
  • 00:10:51 rule of thumb is I shouldn't ever load
  • 00:10:54 data i'm not rendering so if i'm not
  • 00:10:57 displaying it on the page i need to
  • 00:10:59 structure my data in a different way
  • 00:11:00 where i can fetch it and be more
  • 00:11:02 specific
  • 00:11:03 and I think being specific and you know
  • 00:11:05 using that rule of thumb of saying I'm
  • 00:11:07 only going to fetch what I render really
  • 00:11:09 helps define your structure because you
  • 00:11:10 can kind of work backwards with firebase
  • 00:11:12 a lot of the time you're not building a
  • 00:11:15 bunch of data into your database and
  • 00:11:17 then building a UI on top of it so
  • 00:11:19 that's traditionally what you kind of do
  • 00:11:21 you have like some set and then you
  • 00:11:23 would build the UI second but let
  • 00:11:25 firebase since it's so easy to write
  • 00:11:26 data people build up the UI they build
  • 00:11:29 up the in your app and they start
  • 00:11:31 writing data from the app and as you're
  • 00:11:33 doing that you can say alright I'm
  • 00:11:34 writing it back and now I'm pulling it
  • 00:11:36 back into my app but I really have some
  • 00:11:40 use case where I need a room title and I
  • 00:11:43 need the data was created but I don't
  • 00:11:45 need messages so that's a situation
  • 00:11:47 where you want stuff I can say all right
  • 00:11:48 is storing us all in one location the
  • 00:11:50 most reasonable or should I have
  • 00:11:52 something like slash rooms your rooms –
  • 00:11:57 metadata or something and have under
  • 00:12:00 that just those two fields that I want
  • 00:12:02 of title and you know created because
  • 00:12:07 that way I now have a specific location
  • 00:12:09 I can look at that has the exact date I
  • 00:12:11 did and so as you're building an
  • 00:12:14 application just always keeping that in
  • 00:12:15 mind that you don't want to fetch what
  • 00:12:17 you're not going to render it kind of
  • 00:12:19 just exposes itself the big issues with
  • 00:12:22 these are with this methodology is that
  • 00:12:25 you might not always know how you're
  • 00:12:26 going to display it right like if I'm
  • 00:12:28 building an application and I find out
  • 00:12:30 six months after I finish this that well
  • 00:12:32 I really need this different view of my
  • 00:12:35 data this is a situation that cloud
  • 00:12:37 functions really helps out with this is
  • 00:12:39 what you can do now is use cloud
  • 00:12:41 functions to build basically views of
  • 00:12:43 your data so what you do is you write a
  • 00:12:45 little function and you have like rooms
  • 00:12:47 and you say all right every time
  • 00:12:49 somebody writes to one of these keys
  • 00:12:52 then go and maintain this other
  • 00:12:55 structure for instance to make rooms
  • 00:12:57 meta put it with the same key and just
  • 00:12:59 joy totally created so that you're doing
  • 00:13:01 that you're writing it and it's being
  • 00:13:03 stored there but then it's super easy
  • 00:13:04 you can zoom on again and you're not
  • 00:13:06 doing you know anything complex they're
  • 00:13:08 just reading and writing a couple of
  • 00:13:10 feels but now you have a really really
  • 00:13:12 efficient way to read that and that's
  • 00:13:14 more general theory even separate from
  • 00:13:17 firebases it's like optimized for read
  • 00:13:18 yes because people are going to read
  • 00:13:20 content in a thousand times more than
  • 00:13:21 they'll ever create it yes this is the
  • 00:13:23 nature of application so you can cut
  • 00:13:26 functions to build up different views
  • 00:13:28 and things like that is a really
  • 00:13:29 powerful tool to keep that flexibility
  • 00:13:32 even after you've really you know
  • 00:13:34 defined destruction that happened within
  • 00:13:35 yeah and in general a good idea to also
  • 00:13:38 kind of get some code out of like your
  • 00:13:41 fronted what it does we belong if you
  • 00:13:43 want to store something you can even
  • 00:13:45 make like 10 SDK calls and write the
  • 00:13:47 different pieces and you see resolve to
  • 00:13:49 get that for each callback or you just
  • 00:13:51 make that one call or queue which are
  • 00:13:53 really related to your front-end you
  • 00:13:55 know let's punch through the rest like
  • 00:13:56 egos absolutely yeah and it worked
  • 00:13:58 really really well and it allows you to
  • 00:14:00 have just one you know main track
  • 00:14:03 objects like this is a chatroom object
  • 00:14:06 and I will write to that and assume is
  • 00:14:07 all right so that kicked off a function
  • 00:14:09 renders to reviews update to my profile
  • 00:14:11 to say our last talked in this chat at
  • 00:14:13 this time and does all of that so your
  • 00:14:15 client side logic say it's super simple
  • 00:14:17 it's one right but you get all this rich
  • 00:14:19 data being written and spread out across
  • 00:14:21 forever is super useful
  • 00:14:23 there's Lansing which is pretty useful
  • 00:14:25 because now we did talked about these
  • 00:14:27 example structures but obviously there
  • 00:14:29 is also place to read about it and
  • 00:14:31 that's documentation which kind of
  • 00:14:32 explains the things we all cover like
  • 00:14:35 we're having different rooms and
  • 00:14:36 structures and you can basically read
  • 00:14:38 Olympic there to get some ideas or it
  • 00:14:41 was too quick or anyone's I deeper into
  • 00:14:43 that so that's also a good good resource
  • 00:14:45 but the end result just practicing lets
  • 00:14:48 me and you will probably hit the point
  • 00:14:49 where your application such as say that
  • 00:14:52 does need or the other way around and
  • 00:14:53 the important thing to keep in mind
  • 00:14:55 maybe is that it doesn't cost you more
  • 00:14:58 to add more notes or more top level to
  • 00:15:01 make it and then yet of course storing
  • 00:15:03 more cost you more but it just plated up
  • 00:15:06 it does question yeah the the amount of
  • 00:15:09 the amount cost of duplicating something
  • 00:15:11 even a ton of locations is just much and
  • 00:15:14 it's going to be way more performant if
  • 00:15:16 your app is for your effort every time
  • 00:15:18 you look and you pull that data it's
  • 00:15:19 exactly what you need to render it may
  • 00:15:21 be super fast that's because that's
  • 00:15:22 something which can be challenging
  • 00:15:24 especially if you have a sequel
  • 00:15:26 background record because there you try
  • 00:15:28 to
  • 00:15:28 come up with a schema where everything
  • 00:15:30 is s has it's less redundancy as pop you
  • 00:15:32 want to have one general which manages
  • 00:15:34 one thing and never want to duplicate
  • 00:15:37 data and that's kind of the important
  • 00:15:39 switcher to make in your head now it's
  • 00:15:41 okay to have some redundancy yeah it is
  • 00:15:44 and it's you know normalization
  • 00:15:46 generalization all you know classic
  • 00:15:48 database concept we do kind of flip them
  • 00:15:51 on their head here and it's because
  • 00:15:52 firebase real from database is
  • 00:15:53 fundamentally a different type of
  • 00:15:54 database and it's not just different in
  • 00:15:57 terms of how you're interact with it but
  • 00:15:59 it's different on a technical level when
  • 00:16:01 you when you're thinking about building
  • 00:16:03 on top of it so yeah a lot of our
  • 00:16:05 classic sequel rules just don't apply
  • 00:16:06 anymore
  • 00:16:07 and like if you're using sequel
  • 00:16:09 definitely do those things but in real
  • 00:16:11 time database we make use of the fact
  • 00:16:13 that storage is cheap and we build
  • 00:16:15 structures out of duplicated it makes a
  • 00:16:17 lot of sense so I think a nice next step
  • 00:16:20 is to look at the rules and those rules
  • 00:16:22 obviously another super important
  • 00:16:24 feature because what you could wonder
  • 00:16:26 right now is that we have ways to store
  • 00:16:28 data we know how to structure it but how
  • 00:16:30 do we actually make sure that we only
  • 00:16:32 store the data we want to store and that
  • 00:16:34 oh you people who are our users what
  • 00:16:36 allows you to store data well are able
  • 00:16:38 to so if I look at this another
  • 00:16:40 legitimate fantastic