1
00:00:00,780 --> 00:00:05,400
We are now able to sign up for new account and when we do so we get back that Jason Webb token which

2
00:00:05,400 --> 00:00:06,720
means everything is looking pretty good.

3
00:00:07,110 --> 00:00:12,750
Well almost as usual still one or two very small things I want to point out when we do this request

4
00:00:12,750 --> 00:00:13,440
to sign up.

5
00:00:13,710 --> 00:00:17,110
Notice how we are sending back our complete user model.

6
00:00:17,100 --> 00:00:21,690
There's a couple of issues with this response right now sending back the User model is not the worst

7
00:00:21,690 --> 00:00:22,560
thing in the world.

8
00:00:22,590 --> 00:00:27,270
During that sign up request because it's going to allow whoever made this request to see.

9
00:00:27,360 --> 00:00:33,620
Well our definition of this person so we can confirm say the email was signed up with correctly.

10
00:00:33,630 --> 00:00:36,440
Maybe there is the idea that we want to use immediately.

11
00:00:36,480 --> 00:00:39,710
There's definitely some information site here that we want to make use of.

12
00:00:39,730 --> 00:00:42,990
However there are other properties that definitely should not be in here.

13
00:00:43,010 --> 00:00:47,400
So for example obviously the password should not be included in the response.

14
00:00:47,400 --> 00:00:53,400
In addition there's this other flag or other property of underscore underscore the that's tied to Mongoose

15
00:00:53,430 --> 00:00:56,340
and it's something it's actually gonna be relevant later on said of course.

16
00:00:56,340 --> 00:01:00,710
But right now we're just going to say that we really don't want to add that property inside this response.

17
00:01:00,900 --> 00:01:04,870
So we definitely want to make sure that we remove password and underscore underscore.

18
00:01:05,280 --> 00:01:07,380
Now normally that would be a very simple thing to do.

19
00:01:07,410 --> 00:01:12,870
But while there is a reason I'm making this into a longer discussion let me tell you what this reason

20
00:01:12,900 --> 00:01:16,730
is or what the kind of issue here is art.

21
00:01:16,820 --> 00:01:20,930
So as usual remember we've got our all service orders and payments.

22
00:01:20,930 --> 00:01:25,670
And even though we are building all this stuff out using note in Express it is entirely possible if

23
00:01:25,670 --> 00:01:29,840
you ever start to really build out a micro services application that you're different services will

24
00:01:29,840 --> 00:01:31,520
have different implementations.

25
00:01:31,520 --> 00:01:37,160
So Ruby on Rails Java spring whatever else in addition to having different code or languages inside

26
00:01:37,160 --> 00:01:42,200
these each of these services they also might have their own different databases different databases

27
00:01:42,200 --> 00:01:45,310
to suit different needs for each service.

28
00:01:45,320 --> 00:01:47,930
So right now on our off service we are making use of Mongo DB.

29
00:01:48,380 --> 00:01:50,950
But you might be working on a service at some point the future.

30
00:01:50,990 --> 00:01:57,780
The same exact project that instead uses my Eskew L or another one that uses Postgres.

31
00:01:57,800 --> 00:02:02,480
So is there anything that's gonna come up as we start to look at using these different databases.

32
00:02:02,480 --> 00:02:04,490
Any big issues perhaps.

33
00:02:04,490 --> 00:02:06,410
Well there definitely is.

34
00:02:06,410 --> 00:02:10,230
I want you to consider a very simple little funny thing.

35
00:02:10,340 --> 00:02:17,290
So we are making use of Mongo D.B. Mongo has some very interesting semantics around the I.D. field Mongo

36
00:02:17,300 --> 00:02:26,520
DV internally records the I.D. as underscore I.D. and you can even see that with the response we got

37
00:02:26,520 --> 00:02:27,390
back inside of postmen.

38
00:02:27,390 --> 00:02:34,550
We've got underscore I.D. right here that is the idea of this record Mongo TB is the only database out

39
00:02:34,550 --> 00:02:38,510
of these three at least perhaps are others out there I want to say the only data base in the world but

40
00:02:38,510 --> 00:02:43,700
out of these three it's the only database that uses those semantics reflecting the I.D. as underscore

41
00:02:43,730 --> 00:02:49,680
I.D. my askew will pose a more typical standard of simply I.D..

42
00:02:49,680 --> 00:02:53,140
Same thing with Postgres as well so why is this relevant.

43
00:02:53,140 --> 00:02:56,030
Well it all goes back to our front end application.

44
00:02:56,110 --> 00:03:00,550
Remember we spent a huge amount of time earlier on INSIDE THIS course dealing with making sure that

45
00:03:00,550 --> 00:03:05,260
we always had very consistent error messages going back to whoever makes requests.

46
00:03:05,260 --> 00:03:10,750
We need to make sure that the exact same is true as much as possible whenever we attempt to fetch normal

47
00:03:10,780 --> 00:03:12,290
data as well.

48
00:03:12,310 --> 00:03:18,160
So if I make a request to my all service orders or payments asking for just one record or trying to

49
00:03:18,160 --> 00:03:26,380
sign up Rita order read a payment whatever it is I would expect on my front end to always get consistent

50
00:03:26,380 --> 00:03:28,180
looking responses.

51
00:03:28,180 --> 00:03:33,700
And that means that rather than having underscore I.D. right here which is very atypical in general

52
00:03:34,240 --> 00:03:38,380
really we want to have simply I.D. And that's pretty much it.

53
00:03:38,380 --> 00:03:40,300
That's what I'm making this big deal around.

54
00:03:40,300 --> 00:03:44,400
We don't want to have these semantics that are very specific to Mongo DB.

55
00:03:44,530 --> 00:03:50,380
Being exposed on our front end instead we want to have very consistent responses no matter what we are

56
00:03:50,380 --> 00:03:56,290
making a request or which service we are making the request to that's pretty much it.

57
00:03:56,370 --> 00:04:02,400
In addition to removing this password field and underscore underscore V we should also do a little bit

58
00:04:02,400 --> 00:04:06,470
of reformatting on that key of underscore idea as well.

59
00:04:06,530 --> 00:04:12,000
Now we can definitely take care of this very easily back inside of our sign up request handler.

60
00:04:12,000 --> 00:04:17,670
So right here we could add in just a little bit of logic to just pull out say the email and the I.D.

61
00:04:18,380 --> 00:04:22,200
reads a sign that I.D. property to a better key or something like that.

62
00:04:22,350 --> 00:04:26,580
But there's really definitely a better way of handling this and making sure that we only have to worry

63
00:04:26,580 --> 00:04:32,490
about this in one single location inside of our codebase rather than having to duplicate this I.D. remapping

64
00:04:32,490 --> 00:04:37,730
logic and all that stuff inside of other root handlers like sign in or current user as well.

65
00:04:37,830 --> 00:04:40,620
Now that we understand the issue let's fix this up in just a moment.