1
00:00:02,160 --> 00:00:04,510
So what is browser storage?

2
00:00:04,570 --> 00:00:07,530
Now as I mentioned, we have the browser and we have the server,

3
00:00:07,530 --> 00:00:12,830
these are the two pieces that typically interact when we're serving a web page,

4
00:00:12,840 --> 00:00:20,790
the web page runs in the browser but a) it's served by a server and b) most web applications also talk

5
00:00:20,790 --> 00:00:27,210
to a server, either behind the scenes through Javascript or by using the default browser behavior where

6
00:00:27,210 --> 00:00:32,510
for example you can submit a form and the request is issued to the server.

7
00:00:32,530 --> 00:00:36,900
Now the server then has a server-side database where data can be stored,

8
00:00:36,900 --> 00:00:39,990
the browser also has a couple of storage mechanisms.

9
00:00:39,990 --> 00:00:41,180
So this is the big picture

10
00:00:41,190 --> 00:00:45,720
but now let's dive into two sides here. For the server side,

11
00:00:45,750 --> 00:00:53,370
so for the data which we send to the server with a HttpRequest, we typically store the important data,

12
00:00:53,460 --> 00:00:56,170
the data which also needs to persist, the data

13
00:00:56,170 --> 00:01:02,610
we also want to store locked away from the users because for example if we have a list of all users

14
00:01:02,610 --> 00:01:09,180
with all their e-mail addresses, of course that has to be stored on one central server. When we stored

15
00:01:09,180 --> 00:01:13,530
something in the browser, then we effectively store it on the machine of our user,

16
00:01:13,530 --> 00:01:15,640
so on your computer for example.

17
00:01:15,840 --> 00:01:20,050
Now of course the implication of that is that this a) is data

18
00:01:20,100 --> 00:01:27,540
we as the application developer can not always tap into, only when you're visiting our page we can basically

19
00:01:27,540 --> 00:01:33,000
use the Javascript code to interact with the browser storage, so the data is not always available to

20
00:01:33,000 --> 00:01:33,590
us

21
00:01:33,660 --> 00:01:36,680
and in addition it also can't be shared with other users.

22
00:01:36,720 --> 00:01:42,630
So the browser storage is really limited in scenarios where it makes sense,

23
00:01:42,630 --> 00:01:48,360
for example if you're building an online shop, of course you wouldn't store the products or the orders

24
00:01:48,420 --> 00:01:54,540
or anything like that in the browser because you need to share the products with the other users, with

25
00:01:54,570 --> 00:01:56,870
all users of your web application,

26
00:01:56,910 --> 00:02:03,510
therefore such data needs to be stored on your server. The orders of course belong to a single user but

27
00:02:03,510 --> 00:02:08,940
you as the owner of the shop also need access to them so that you can fulfill them and therefore that

28
00:02:08,940 --> 00:02:12,250
would also be stored on a server side database.

29
00:02:12,250 --> 00:02:19,060
Now one thing however you could consider storing in the browser would be the shopping cart, the current

30
00:02:19,060 --> 00:02:20,580
shopping cart of the user,

31
00:02:20,590 --> 00:02:22,480
it only matters to that user

32
00:02:22,690 --> 00:02:28,180
and you might not need to store it on your servers. If you're not running any analytics on that or something

33
00:02:28,180 --> 00:02:31,650
like that, you can store it just where your user is,

34
00:02:31,660 --> 00:02:33,640
so in the browser of the user,

35
00:02:33,640 --> 00:02:39,650
same is true for authentication data, like a session ID, such data could be stored in a browser,

36
00:02:39,670 --> 00:02:46,330
so temporary data or convenience data which might improve the user experience but which is not essential

37
00:02:46,330 --> 00:02:48,540
to your entire offering.

38
00:02:48,550 --> 00:02:53,190
Now when we talk about browser storage, we got three major storage types -

39
00:02:53,200 --> 00:02:56,710
we got local storage and session storage which are very related

40
00:02:56,710 --> 00:03:01,780
and I'll explain the difference in this module, we get cookies and we got IndexedDB

41
00:03:01,780 --> 00:03:06,190
Now let's learn about the differences between these different storage engines, between local storage

42
00:03:06,190 --> 00:03:11,990
cookies and IndexedDB. Local storage and session storage is a simple key-value store,

43
00:03:12,010 --> 00:03:16,480
so it's like a Javascript object which we save in a file,

44
00:03:16,480 --> 00:03:19,790
so it's basically just a couple of key-value pairs.

45
00:03:19,960 --> 00:03:24,730
You could use that to store for example session ID of a user,

46
00:03:24,730 --> 00:03:30,280
some analytics key which you need to send to your analytics servers, something like that,

47
00:03:30,280 --> 00:03:36,260
so often you use local storage to manage user preferences or basic user data.

48
00:03:36,640 --> 00:03:44,470
You can tap into local storage with the help of Javascript and only Javascript, so only the Javascript

49
00:03:44,470 --> 00:03:49,480
code that runs in the browser is able to communicate with local storage.

50
00:03:49,570 --> 00:03:55,480
It's easy to use, quite versatile but of course it's bad for complex data because it's just a key-value

51
00:03:55,480 --> 00:03:56,180
store,

52
00:03:56,200 --> 00:04:02,350
so if you would be building a rich web application, like Google Sheets for example where you might need

53
00:04:02,350 --> 00:04:08,080
to store a lot of complex data in the browser as well, then this is not really a great option.

54
00:04:08,080 --> 00:04:16,300
Now also a relatively simple storage is cookies. Now cookies are also key-value pairs in the end,

55
00:04:16,570 --> 00:04:22,630
though we can configure them in various ways, for example we can set a cookie to expire at some time

56
00:04:22,630 --> 00:04:27,550
in the future so that it automatically gets deleted basically, for local storage

57
00:04:27,550 --> 00:04:32,320
we can also delete data but we have to do that manually through Javascript, for cookies we could set

58
00:04:32,320 --> 00:04:35,290
it as an option on one of our entries.

59
00:04:35,380 --> 00:04:42,070
We also since it's still relatively simple use it to manage basic preferences, session IDs, stuff like

60
00:04:42,070 --> 00:04:49,000
that and we can also access and clear it with Javascript, just like local storage by the way because

61
00:04:49,000 --> 00:04:54,160
I didn't mention it there, the user also can clear all that data through the developer tools, through the

62
00:04:54,160 --> 00:04:58,790
browser settings where you can clear all local data, that is possible.

63
00:04:58,800 --> 00:05:03,390
Now the special thing about the cookie is that it's a bit more clunky to use than local storage,

64
00:05:03,390 --> 00:05:05,680
it's not having such a nice API

65
00:05:05,700 --> 00:05:07,060
for working with it.

66
00:05:07,120 --> 00:05:13,780
It's equally versatile though, maybe a bit more even because you can set expiry dates and and that's really

67
00:05:13,780 --> 00:05:14,470
different,

68
00:05:14,560 --> 00:05:20,830
cookies also typically are sent to the server with outgoing HttpRequests.

69
00:05:20,830 --> 00:05:28,390
So cookies, unlike local storage and session storage can also be read by the server because they're attached

70
00:05:28,390 --> 00:05:32,950
to outgoing HttpRequests in the headers of these requests,

71
00:05:32,950 --> 00:05:35,600
so that can be an extra plus.

72
00:05:35,680 --> 00:05:43,120
Now just like local storage because they're simple key-value stores, they're not suited for more complex

73
00:05:43,120 --> 00:05:44,010
data

74
00:05:44,230 --> 00:05:50,680
and then we get IndexedDB. IndexedDB is the most sophisticated storage device amongst these three,

75
00:05:50,770 --> 00:05:57,400
it's a client side database in the end, built into the browser which you can use with a query language,

76
00:05:57,400 --> 00:06:01,150
you can run more or less complex queries against IndexedDB,

77
00:06:01,300 --> 00:06:07,120
you can therefore manage complex data in there because you can have different tables with records that

78
00:06:07,120 --> 00:06:13,720
are connected and so on and you can access it with Javascript, you can also clear it with Javascript and

79
00:06:13,720 --> 00:06:20,890
just like all browser side storages, the user can always clear and erase all that data with a click

80
00:06:20,890 --> 00:06:26,950
of a button in the preferences and therefore none of these storages should be a storage you rely on.

81
00:06:27,220 --> 00:06:31,960
You can use it to improve the user experience but you have to live with the fact that your user can

82
00:06:31,960 --> 00:06:32,850
always clear these

83
00:06:32,870 --> 00:06:39,250
storages. Now IndexedDB is also a bit clunky to use, it has a Javascript API but that is a bit annoying

84
00:06:39,340 --> 00:06:42,720
and it's great for complex non-critical data,

85
00:06:42,850 --> 00:06:48,550
it offers quite good performance so it's really good if you have complex data in your application.

86
00:06:48,550 --> 00:06:53,620
I will say though, I'm really talking about rich client side applications there, something like Google

87
00:06:53,620 --> 00:06:54,680
Sheets and so on,

88
00:06:54,700 --> 00:07:00,250
so where you basically build a desktop level application in the browser and you might need to store

89
00:07:00,250 --> 00:07:07,000
a lot of temporary or see my temporary data in some storage on the browser and you don't want to store

90
00:07:07,000 --> 00:07:11,640
that on a server for whatever reason because you want to make sure that your application works

91
00:07:11,880 --> 00:07:17,110
offline or anything like that, then this could be used, in a lot of applications

92
00:07:17,130 --> 00:07:19,380
you'll not really need IndexedDB.