Design Problem: Data Fetching Scheme of Zoom Debugger

I present a design problem I encountered while working on the zoom debugger and how I resolved it, at least for the moment. I hope this can be instructive for some developers towards solving problems of their own.

Transcript

The following transcript was automatically generated by an algorithm.

00:00 : hello there um i want to share a
00:03 : story of a problem a design problem
00:06 : that i uh faced today and came up with a
00:09 : solution
00:10 : for in particular a
00:13 : uh sort of a dynamic data fetching
00:16 : scheme
00:17 : maybe i should just call it a new
00:20 : fetching scheme
00:21 : for objects in
00:24 : in the time traveling debugger that i'm
00:26 : working on
00:28 : um i want to share this because i think
00:31 : uh some there's a few things about it
00:34 : that the way i the way the problem
00:37 : first occurred to me and then
00:41 : the way that as i approach the problem
00:45 : um the way that my
00:49 : my conception of the problem kind of
00:51 : changed over time
00:53 : uh and that aspect of it i think
00:56 : can be instructive for can be
01:00 : instructive for developers uh which is
01:02 : why i want to share this
01:04 : uh first of all um as writing
01:08 : down uh sort of um
01:12 : but by the way well whenever i uh
01:15 : whenever i encounter a difficult
01:18 : problem and this one was definitely
01:22 : definitely should be categorized that
01:24 : way as a difficult problem
01:26 : whenever i do have to do that i i
01:30 : usually
01:32 : go into a brainstorming mode
01:36 : and and there are various ways that i
01:39 : brainstorm
01:40 : sometimes i brainstorm by just pacing in
01:43 : a room
01:43 : back and forth holding my head down
01:47 : and just be sort of consumed by deep
01:51 : thought other times i am doing that
01:54 : while i'm driving
01:55 : the car uh probably not the safest thing
01:58 : to be doing
02:00 : but other times while i'm doing other
02:02 : stuff but uh one of
02:03 : the better ways that i do brainstorming
02:07 : is with a
02:08 : pen and notebook and in this case with
02:10 : uh
02:11 : several different colored pens so i have
02:14 : these
02:14 : colored pens that i use
02:18 : which i love and i want to share my
02:21 : notes with you
02:22 : so first um
02:26 : first i uh came up i was
02:30 : thinking very hard about two different
02:32 : approaches
02:33 : the current approach versus
02:36 : which i have listed here as one and two
02:40 : so approach one was um
02:44 : i would fetch the objects lazily
02:47 : as the user interface required them
02:51 : um so first to give you some context
02:55 : the user interface that we're talking
02:57 : about
02:58 : this is the user interface that i
03:02 : am working on and have been working on
03:04 : for a while
03:05 : i call it the deep zoom debugger
03:10 : so you can zoom in due to
03:14 : a to a sort of execution of a piece of
03:17 : kit
03:22 : and if you zoom in
03:25 : into a particular function call you can
03:28 : see the details of
03:29 : what happened during the execution of
03:32 : that function and then
03:34 : because functions can call other
03:35 : functions can call other functions
03:37 : you can zoom in more and more and more
03:40 : and so forth while you're looking at
03:43 : this code you also get information about
03:47 : like the state of some variables in in
03:49 : the code
03:51 : so um so i have built several
03:54 : versions of this or this this code has
03:57 : evolved over time
03:59 : the current problem that i'm facing is
04:03 : recently i have managed to
04:06 : log the the state of the program
04:09 : uh into a database as a series of
04:12 : snapshots
04:14 : okay so every single snapshot of the
04:16 : state of the program is
04:18 : stored in this snapshot table
04:21 : and each snapshot contains a stack
04:25 : and a heap but those fields are actually
04:28 : pointers to something in the object
04:31 : table and in the object table is where
04:34 : all the
04:34 : data of the program actually live so
04:38 : and also an object
04:41 : um store like this is in a
04:44 : semi json format uh for people who has
04:48 : been following my
04:49 : status updates you you're familiar with
04:51 : this but um
04:53 : for those who are not um this guy
04:56 : here um there's a notation
05:00 : here that i use this star here star 17
05:05 : means this value actually points to
05:07 : object 17
05:08 : in this table based on this id so
05:11 : if i want to we first read in this
05:15 : object which contains
05:18 : a board a player zero one and two but in
05:21 : order to figure out what is actually in
05:23 : board we actually have to then fetch
05:26 : object 17 and uh an object 17 is
05:30 : actually a
05:31 : heap reference that's how how i decided
05:34 : to
05:35 : denote heap references it's an empty an
05:37 : object with just an id
05:39 : and that's actually pointing to one
05:42 : but that's number one in the heap and
05:45 : there's
05:46 : another way um i probably
05:49 : don't have time to describe how the heap
05:52 : works right now so i'm gonna skip over
05:54 : that
05:55 : but point being that i
05:58 : have a large database of objects
06:02 : within each object there could
06:03 : potentially be a reference to
06:05 : other objects so
06:08 : so you're looking at something like
06:12 : you're looking at something like okay so
06:15 : for each snapshot
06:22 : for each snapshot it
06:25 : let me draw this like this so for each
06:28 : snapshot object
06:29 : you've got a stack which is a pointer
06:33 : to some object which is in that object
06:38 : table you also got a heap which also is
06:41 : a pointer to some object
06:44 : the stack contains stuff inside it which
06:48 : point to other objects
06:53 : and would in turn can contain pointers
06:56 : to
06:57 : yet other objects and the same can be
06:59 : said of the heap
07:01 : the heap is actually a huge bag of
07:03 : objects
07:04 : so potentially huge bag of objects
07:07 : and in the scenario of my little
07:10 : tic-tac-toe game it
07:12 : evidently be did become a very very
07:16 : large bag of objects um
07:19 : okay so and but the objects
07:22 : could in turn have pointers to other
07:25 : objects and so forth and it could could
07:27 : go kind of
07:28 : you know pretty pretty you could could
07:31 : go
07:32 : several hops until you get the entire
07:34 : graph of
07:35 : objects that are required uh that are
07:38 : sort of transitively referenced by this
07:41 : snapshot
07:42 : if you walk all of these references you
07:44 : could potentially get
07:46 : a large number of objects um
07:49 : so so given all of that
07:53 : um my approach one which
07:56 : is what i initially went for is
07:59 : load these objects recursively and
08:03 : on demand in a lazy fashion
08:08 : in a lazy fashion which means uh
08:13 : i'm going to sort of first just
08:16 : load in the snapshot and then we're
08:18 : going to load in
08:19 : this stack object and this heap object
08:23 : and then if i've got front end code that
08:26 : wants to look at
08:28 : what this pointer is pointing to
08:31 : then it would it would request a fetch
08:34 : of this object and if i've got code that
08:37 : actually wants to
08:38 : see what this is pointing to and then at
08:41 : that point it will
08:42 : lazily fetch uh this object and so forth
08:45 : so all objects
08:46 : are fetched lazily um
08:49 : i'm i think i'm going i might if it's
08:52 : not too much trouble
08:55 : i'm gonna switch to the branch of code
08:58 : that
08:59 : still uses that approach
09:05 : i think that one is called database and
09:07 : show you what that looks like
09:09 : in code so this is the state of the code
09:14 : at the beginning of this problem solving
09:18 : session
09:18 : or not the beginning but it is the first
09:21 : draft of this
09:22 : problem solving in which i took
09:25 : approach number one um
09:31 : and you can kind of see that these
09:34 : orange parts that are displaying the
09:38 : values of
09:39 : variables they actually came in
09:43 : a little bit later quite a bit later
09:45 : than the
09:46 : source code did i'll show you that again
09:49 : so you can see these orange bits yeah
09:52 : they're sort of like
09:53 : coming in late late to the party
09:57 : like a movie star um and the reason
10:01 : for that is because of the lazy loading
10:03 : scheme
10:05 : i have code
10:08 : here this is the code that loads in that
10:10 : information
10:11 : a code that is like taking the
10:14 : the stack this stack is actually just a
10:17 : reference
10:18 : to the stack in order to actually get
10:19 : the actual stack
10:21 : it has to ask the object cache
10:24 : for the stack and the first thing you
10:27 : get
10:27 : these the object of this id
10:31 : from the object cache it will return
10:34 : null
10:35 : back so it will say oh if the cache
10:37 : doesn't have it yet
10:39 : i'm going to not display anything which
10:42 : in this
10:42 : function you do that by returning an
10:45 : empty array
10:46 : but if it is there then
10:49 : we'll have to sort of look up yet
10:51 : another reference
10:53 : it's kind of this this is actually the
10:56 : case where like oh
10:57 : i need to fetch this guy and if it's
11:00 : not fetched yet then it'll this get will
11:03 : actually trigger
11:04 : the object cache to fetch it from the
11:06 : server
11:07 : and then when the server returns that
11:10 : then it
11:10 : it triggers another render which would
11:13 : in turn
11:14 : re-trigger this this method getting
11:17 : called and when
11:18 : that re-trigger the next time this will
11:21 : return an
11:22 : actual stack and allow it to go through
11:24 : but the next time
11:26 : it actually it's going to ask for this
11:28 : guy and then
11:29 : when it asks for this guy the first time
11:32 : it won't have
11:33 : a result for that one yet the object
11:36 : cast is going to go fetch it
11:37 : and then this time it'll return md but
11:40 : then the next time
11:42 : when the render is again re-triggered it
11:45 : can
11:45 : go further into the next step so as you
11:48 : can imagine if we have several of these
11:50 : steps
11:51 : which did end up happening in a
11:54 : different method where we have like
11:56 : this is like step one step two step
12:00 : three each
12:00 : step causes a lazy fetch if you have a
12:03 : lot of those steps
12:05 : um it actually could take a while
12:08 : for all the information to get here
12:11 : because
12:12 : each request is a round trip to the
12:14 : server and
12:15 : if and they have to happen serially
12:20 : and and that's actually one of the uh
12:23 : one of the problems with this approach
12:25 : which i
12:26 : actually didn't even write it down in my
12:28 : pros and cons list
12:30 : oh where's my pros and cons oh there it
12:32 : is
12:33 : okay this is my pros and cons list
12:37 : doing pros and cons is very important
12:40 : uh in your in your problem solving i
12:43 : i feel like because a lot of times you
12:45 : can feel
12:47 : like you're very attached to one
12:49 : solution versus another
12:51 : but is only when you list the pros and
12:54 : cons of each
12:55 : that you're able to think in a more
12:58 : unbiased way
12:59 : or in a less biased way um okay so
13:02 : anyway
13:03 : the approach approach number one was
13:05 : fetch the objects
13:06 : recursively and an approach number two
13:09 : what was the opposite of
13:11 : fetching the objects lazily well
13:14 : it's to prefetch the objects so this
13:17 : approach number two have an api in the
13:19 : back end that recursively fetches
13:22 : objects on the behalf of a single
13:24 : function call
13:25 : so what does that look like well that
13:27 : looks like this
13:30 : basically that graph
13:35 : well i deleted that graph but um i'll
13:38 : just redraw
13:38 : a simpler version of that or
13:42 : perhaps a slightly different version of
13:43 : that so i have a snapshot
13:45 : and again it's got a stack pointer
13:50 : stack does that look like stack and a
13:53 : heat pointer
13:55 : among some other stuff and each of them
13:58 : are
13:58 : sort of pointing to this objects and
14:02 : objects can be pointing to other objects
14:08 : and so forth
14:17 : and this could get i don't know
14:21 : somewhat deep um so
14:25 : the other approach is like you make an
14:28 : api
14:28 : call to the back end and the back end
14:31 : does the work of
14:32 : traversing all of these objects for you
14:35 : and then returns all of these objects
14:37 : back to the front end
14:40 : so so
14:43 : so all of these these object traversal
14:47 : of
14:48 : um the back end basically ends up
14:51 : generating this
14:52 : subtree for you and returns it all to
14:56 : the front end um
14:58 : and and so i was
15:01 : comparing these two approaches and um
15:07 : did i i don't remember when
15:10 : i implemented number two
15:14 : well so the let's go through the pros
15:17 : and cons
15:18 : the cons of number one versus number two
15:21 : the concept number one
15:23 : is the track the the
15:26 : if statement checks in the front end are
15:28 : get were getting pretty ungainly
15:31 : so in particular this one and this one i
15:35 : i was having in
15:38 : here that is getting kind of ungainly
15:43 : now you usually write it the most
15:45 : straightforward way the first time
15:46 : through
15:47 : so i i was doing this without trying to
15:50 : sort of simplify the syntax or or
15:52 : extract the syntax out
15:54 : but still this syntax is getting
15:56 : ungainly that's the first cons of
15:58 : approach number one approach number two
16:01 : was that
16:02 : um uh
16:06 : oh oh sorry that was the cons of
16:08 : approach number one let's go to another
16:10 : con of
16:11 : number one number another con of number
16:14 : one was
16:15 : lots and lots of network calls which
16:18 : we we did end up seeing
16:22 : i'll show you um so if i go to the
16:25 : network tab
16:27 : as you can imagine because when there
16:29 : are lots of objects and you're trying to
16:31 : recursively load
16:32 : all of them uh we're getting this
16:34 : network call count when we're loading in
16:37 : this information getting 98 requests at
16:40 : this level
16:40 : um if we drill into another level
16:44 : another one that has more complicated
16:46 : stuff in it
16:47 : say this one our request count
16:51 : jump to yeah close to 300
16:55 : at this point and if we drill down even
16:58 : more then it'll
16:59 : it'll jump more so so it's the the front
17:02 : end is making a request
17:04 : for everyone uh for every one of these
17:08 : hops uh that is needed to get the
17:11 : information
17:12 : that the front-end wants so large amount
17:15 : of requests
17:16 : uh okay so these two
17:19 : were the cons to approach number one
17:22 : that i've identified uh what about the
17:25 : cons for
17:26 : approach number two approach number two
17:28 : is that i
17:29 : thought of was you
17:33 : could while you have fewer network calls
17:36 : which is the pro of uh
17:40 : pro of the num approach number two
17:43 : but um if you resolve all of the objects
17:47 : in a graph
17:50 : for every snapshot well some of the
17:52 : objects
17:53 : might be shared by multiple snapshots so
17:57 : so for example i have like if this is
18:00 : snapshot number
18:01 : one i have snapshot
18:04 : number two snapshot number two
18:07 : might actually be pointing to some of
18:10 : the same objects
18:11 : that's possible and it could potentially
18:14 : even be
18:15 : that the the redundancy is a lot
18:18 : as in snapchat number one could be
18:21 : sharing a lot of the same objects
18:23 : with snapshot number two and and if that
18:26 : was the case
18:27 : and i decided to return all of the
18:29 : objects
18:30 : for every snapshot then we would end up
18:34 : transmitting the redundant the same
18:36 : objects redundantly
18:38 : and also if we were sharing them storing
18:41 : them in memory we could
18:42 : also end up storing the objects
18:44 : redundantly in memory
18:46 : so that's i actually didn't realize this
18:50 : after i had implemented approach number
18:53 : two
18:54 : um the back end i'll show you a little
18:57 : bit of
18:58 : how approach number two worked so
19:00 : basically
19:01 : this is the output of approach number
19:04 : two
19:05 : uh although this is in a state where
19:10 : i had another enhancement that came
19:12 : harder but
19:14 : i'm gonna ignore that for now so this is
19:16 : approach number two where
19:18 : it's for a particular function call it
19:21 : fetches all of the child function goals
19:24 : all the snapshots
19:25 : as well as all of the
19:28 : objects that can be referenced
19:32 : from any of these snapshots so it works
19:34 : it walks the graph
19:36 : of say like if this the stack
19:39 : is pointing to object number two then
19:42 : it's gonna go
19:44 : fetch object number two and put it in
19:46 : this object map
19:47 : so uh in this case the stack points to
19:50 : object number
19:52 : 150 to 950 2931
19:59 : so that object is going to get returned
20:02 : later in this object graph where is it
20:07 : there's a lot of objects in here uh i
20:10 : i even forgot the
20:18 : where is it there it is so that that's
20:21 : that
20:22 : that's that object right so so i changed
20:25 : it to work like this
20:27 : and only only after i had implemented
20:31 : this
20:31 : did i realize that we
20:35 : did i realized that this con that we
20:38 : could end up with a lot of
20:40 : redundantly transmitted objects and that
20:42 : actually takes up
20:43 : a lot of bandwidth and also potentially
20:46 : a lot of memory
20:48 : and the pros are actually the reverse of
20:51 : the cons
20:52 : in this case so the pro of approach
20:56 : number one is the
20:57 : the caching it just works very simply
21:02 : there's no need to refetch the same
21:04 : objects but just based on the id and
21:06 : everything is immutable so there's no
21:08 : worrying about whether
21:10 : an object has to been updated and i have
21:12 : to re-fetch it
21:13 : there's none of that and the pros
21:17 : of the pros of approach number two is
21:21 : the front end only has two
21:24 : um there's only one check in the front
21:27 : end to
21:28 : see whether the required data is
21:31 : here or not instead of several of these
21:35 : looking up of the cache and then
21:37 : checking where this
21:38 : where this data is there we would only
21:41 : end up with
21:41 : one of these if we use approach number
21:44 : two and then
21:46 : also a pro of approach number two is we
21:48 : would end up with
21:49 : fewer network calls
21:53 : now one thing to say about situations
21:56 : like this
21:57 : is that i think people
22:00 : very often um
22:05 : sort of put themselves in
22:08 : inside this false dichotomy of
22:12 : well i i can i can only choose one of
22:15 : the two approaches but in fact
22:17 : when you're doing this kind of
22:19 : brainstorming a part of the reason you
22:21 : want to do this kind of
22:23 : higher level brainstorming is to find
22:26 : the solutions that you have not
22:29 : thought of before and usually that
22:33 : comes about by thinking
22:36 : uh sort of very clearly
22:40 : about the pros and cons of each and how
22:43 : each of them
22:45 : it sort of interact or relate to each
22:48 : other
22:48 : or why each of them have those pros and
22:51 : cons and those characteristics so
22:54 : um so when i put all of this stuff on
22:58 : the page
23:00 : i came up with a third option which i
23:03 : called the tweener
23:05 : which is often the case if you want the
23:07 : best of both
23:08 : worlds can you come up with a in between
23:11 : solution
23:12 : and the in between solution that i came
23:15 : up with
23:16 : is how about have an api that
23:19 : recursively
23:20 : fetches objects so just like number two
23:24 : except that you also pass in a list of
23:28 : objects that we already that the front
23:31 : end already has
23:32 : in the already has in the cache so that
23:36 : the back end knows
23:37 : these do not need to be re rescinded
23:41 : back into the front end so that is
23:43 : saying
23:44 : if you have a picture like this actually
23:47 : let me draw another picture because i
23:50 : mean we need more
23:52 : space
23:57 : okay in so we have a scenario where we
24:01 : have a
24:02 : complex graph of objects which is stored
24:05 : in a database in the backend right so
24:08 : gonna call this backend and you want the
24:10 : front end to be able to access
24:13 : that information but not all of it
24:15 : because
24:16 : there's too much information this
24:18 : database is very very large
24:21 : and and the whole point of storing it in
24:23 : the database
24:24 : like look look how many objects we have
24:27 : that that's a lot
24:28 : um so the whole point of storing it into
24:31 : the database is
24:32 : so that we don't have memory issues so
24:35 : we want the front end to have
24:36 : only a partial amount of data
24:39 : that the database has we we want the
24:42 : part
24:43 : the front and to be like a
24:46 : partial mirror of all of the data
24:50 : it's like you only have a small percent
24:52 : of all of the data that the backend has
24:54 : and you can think of it like google
24:57 : earth
24:58 : right google is the concept that i based
25:01 : this
25:01 : thing on and google earth has an
25:05 : incredible amount of data uh embedded in
25:08 : it but at any
25:09 : given moment you're only looking at a
25:12 : very small
25:14 : subset of all of that data so we got all
25:17 : these
25:18 : objects in the back end a
25:21 : like a potentially very very large
25:24 : object graph
25:25 : like this
25:35 : okay that's enough uh the front end
25:37 : wants to be able to say
25:39 : uh okay well there are some snapshots
25:42 : uh i'll call these ss's so snapshot is
25:46 : like an entry point
25:48 : we have a whole bunch of sss
25:52 : let's call this ss1 ss235 4 and so forth
25:57 : and each snapshot sort of points to
26:00 : some object maybe something like this
26:05 : and that that object becomes like the
26:08 : entry point of this snapshot
26:10 : actually each snapshot has multiple
26:12 : pointers but let's simplify a little bit
26:14 : so we want to say basically that
26:17 : when the front end is looking at
26:20 : something that needs this snapshot
26:22 : say actually this slightly more
26:25 : complicated than that
26:27 : even there's there's function calls
26:30 : and that each function call has a
26:32 : collection of snapshots so maybe
26:35 : so each function call has a
26:39 : collection of objects and at any given
26:41 : moment
26:42 : the the front end is like looking at one
26:45 : particular function call
26:47 : well not exactly but we simplify it
26:50 : pretend it is
26:51 : so the front front end is looking at one
26:53 : particular function call
26:55 : say this this smart
26:59 : computer calculated move function call
27:02 : and
27:03 : and it's like hey back-end please load
27:06 : me in
27:07 : all the data i need to see for this
27:09 : function call
27:10 : so send an api call
27:15 : asking for information related to this
27:17 : function call and then we have the api
27:19 : basically
27:20 : go through every snapshot that's related
27:23 : to this function call
27:24 : and then walk the graph walk the stack
27:27 : start at the stack and then heap
27:29 : uh traverse through all the objects that
27:32 : would have been
27:33 : encountered by looking at every snapshot
27:36 : that
27:36 : belongs to that particular function call
27:39 : and you end up with
27:40 : a sub graph of the entire graph that is
27:44 : stored in the database
27:45 : you send that back into the front end
27:48 : and the front end
27:49 : is going to get this graph this sub
27:53 : graph of the objects in this format
27:57 : in this format and the front end is
28:00 : responsible for
28:01 : caching these putting putting it into a
28:03 : cache
28:04 : so there's a cache which is a map
28:11 : so maybe like one you know points to
28:16 : a two points to be
28:20 : three points to c etc where each
28:23 : a has it has like a cross bonding
28:28 : corresponding object in the database so
28:30 : this is like a partial mirror of the
28:32 : database
28:34 : and my idea was like each time i send
28:38 : an api call i also send the list
28:41 : of the ids that are already in my cache
28:44 : here so that the back end will know to
28:47 : skip these that the front end
28:48 : already has okay so so that was
28:52 : my tweener idea however
28:55 : the problem with the tweener idea
28:58 : is that the list could get long the list
29:01 : of all of those ids
29:03 : could get very long and
29:09 : and that could be a problem and then i
29:12 : thought more about
29:13 : whether there's a way to solve that
29:16 : problem and there was it's called
29:18 : sessions his this uh sessions is a
29:21 : concept
29:22 : uh in http servers that has
29:27 : has a long history so we can we can bank
29:30 : on something that has a quite a bit of
29:32 : history
29:33 : which is just http sessions so i
29:36 : implemented http sessions
29:41 : in the server so the server code
29:44 : well you're using this express session
29:47 : module
29:48 : and you just use it like this and we're
29:51 : able to store
29:52 : information related to the session so
29:56 : i used a session to store all the ids
30:00 : that have already been fetched for this
30:02 : particular
30:03 : client and that's remembered
30:07 : uh and during this deep traversal which
30:10 : is implemented by this git
30:12 : object steep uh function if it sees that
30:16 : it's already in that list of ids
30:20 : then it will not do the fetching uh so
30:22 : that's how that works so
30:24 : i'll show you that so initially we
30:27 : made this request to get this
30:30 : very large list of objects if we make
30:32 : the request one more time
30:36 : in the second request we actually get an
30:38 : empty map
30:39 : because all of those uh objects are in
30:43 : the session now and the backend assumes
30:45 : that
30:45 : your your front end already has that in
30:47 : the cache so we don't have to return
30:49 : them again
30:49 : if we fetch uh for a different
30:53 : function called id then we get something
30:56 : a little bit different we
30:57 : we still get some we still get
31:01 : some objects but it's actually not the
31:04 : full set of objects because
31:05 : there's some overlap between the result
31:08 : of this call versus the result of a
31:10 : different
31:11 : function call so we don't get the full
31:14 : set we just get
31:15 : the objects that were missed by default
31:17 : first call
31:19 : uh yeah so that's what i
31:23 : ended up coming up with let me show you
31:26 : the
31:27 : code for that
31:32 : my branch is called data fetching scheme
31:37 : oh yeah okay
31:40 : i'm not gonna bother committing this
31:44 : actually
32:02 : okay let me see
32:05 : if this works out it did compile okay
32:09 : uh look at the network panel uh for how
32:12 : many requests
32:13 : that this ui makes now so we make
32:16 : one request at this level for the main
32:20 : function
32:20 : and once we get here we made a second
32:23 : request
32:24 : for this for rendering this play game
32:27 : function
32:28 : and we drill into the smart computer
32:33 : um we we made five requests
32:36 : so uh i think one for this is winner
32:39 : function and then another one for this
32:41 : smart computer so the number of requests
32:44 : that are needed
32:45 : has dramatically gone down we're
32:48 : literally making one request
32:50 : for per drill down to a function called
32:53 : that we're looking at
32:55 : and that that's basically as good as it
32:57 : can get in
32:58 : in terms of saving network calls
33:01 : um another thing i'm
33:06 : thinking about is the size of the cache
33:09 : in the front end
33:10 : we probably want to control that in some
33:12 : way because i don't
33:13 : want that that number to keep going up
33:17 : i want a scheme for purging
33:20 : objects that are basically no longer
33:23 : being viewed
33:24 : um when when they can be purged
33:27 : so that's something i i'm planning to
33:30 : work on is one of the things on my list
33:32 : right now but i think that's
33:33 : doable with the scheme that i have uh
33:36 : okay i'm gonna leave you with some
33:38 : closing remarks
33:40 : um and
33:44 : okay what are my closing remarks uh
33:48 : one thing i want to mention that i wrote
33:50 : down here
33:51 : i wrote down know that i should make a
33:53 : video which is what i'm doing right now
33:55 : um the other factor i also just talked
33:59 : about i
33:59 : probably want a good scheme for purging
34:01 : objects
34:02 : one more thing i want to mention is
34:04 : confidence
34:05 : that the role of confidence uh
34:09 : that the role that confidence plays
34:14 : in the in the solving of complex
34:17 : problems
34:18 : i feel that it's actually really
34:21 : important
34:22 : to build up your confidence by
34:26 : building the simplistic solution first
34:29 : before you feel confident enough
34:32 : attempting the more sophisticated
34:34 : solutions and that was the case
34:37 : for me um i work with a lot of
34:41 : more junior developers than me
34:44 : that you know can from time to time
34:48 : can feel like
34:51 : you know they don't have the confidence
34:55 : to to
34:56 : to take on the challenges that are in
34:58 : front of them
34:59 : um and i just want you and want them
35:02 : to to know that well that kind of
35:04 : problem
35:05 : exists for a very senior developer
35:08 : as well uh someone like me who has
35:11 : solved
35:12 : like a lot of different problems before
35:15 : and even
35:16 : with all that experience it still
35:19 : was difficult for me jumping right in
35:23 : and attempting the most sophisticated
35:26 : solution
35:27 : because when you're dealing with
35:29 : something that's brand new for you
35:31 : you actually don't have a good footing
35:35 : enough of a footing to know what the
35:37 : potential problems
35:39 : are until you actually get into it which
35:42 : is why it's
35:43 : so important to start with building out
35:46 : the simplistic solution which which
35:49 : for me that was approach number one
35:52 : bridge number one
35:52 : seemed to me to be the more
35:55 : straightforward one
35:56 : to implement and i just did that
36:00 : but when uh when
36:03 : problems surface then that's when
36:06 : i sort of regrouped and did some
36:10 : brainstorming and
36:12 : see if i could come up with a better
36:14 : solution
36:15 : than that and another thing i want to
36:18 : say that
36:19 : is that it's actually
36:22 : very important and very beneficial to
36:25 : try multiple
36:26 : solutions before setting
36:29 : settling on the oh the one that you want
36:33 : at the end and sometimes
36:35 : it may not even be the end sometimes
36:38 : that's just the solution for now and
36:40 : later on you would still
36:41 : have to change it if you encounter other
36:44 : problems
36:45 : um don't look at it as
36:49 : throwaway work um although
36:52 : one way to look at it is like don't
36:54 : don't be
36:55 : afraid of doing throwaway work
36:59 : i have built a lot of things that that i
37:02 : then later thrown away but
37:05 : what would you gain through that
37:07 : experience is
37:09 : the learning that you get from it and
37:11 : being able to compare
37:13 : two different approaches and analyze the
37:16 : pros and cons of
37:17 : each allows you to understand the entire
37:20 : problem
37:21 : better and also allows you to
37:25 : become more skilled level up in your
37:28 : problem solving skills
37:29 : and coding skills as well so that's all
37:32 : i gotta say
37:34 : here uh thank you for watching i and i
37:36 : hope that
37:37 : that was helpful to you