We are now able to sign up for new account and when we do so we get back that Jason Webb token which
means everything is looking pretty good.
Well almost as usual still one or two very small things I want to point out when we do this request
to sign up.
Notice how we are sending back our complete user model.
There's a couple of issues with this response right now sending back the User model is not the worst
thing in the world.
During that sign up request because it's going to allow whoever made this request to see.
Well our definition of this person so we can confirm say the email was signed up with correctly.
Maybe there is the idea that we want to use immediately.
There's definitely some information site here that we want to make use of.
However there are other properties that definitely should not be in here.
So for example obviously the password should not be included in the response.
In addition there's this other flag or other property of underscore underscore the that's tied to Mongoose
and it's something it's actually gonna be relevant later on said of course.
But right now we're just going to say that we really don't want to add that property inside this response.
So we definitely want to make sure that we remove password and underscore underscore.
Now normally that would be a very simple thing to do.
But while there is a reason I'm making this into a longer discussion let me tell you what this reason
is or what the kind of issue here is art.
So as usual remember we've got our all service orders and payments.
And even though we are building all this stuff out using note in Express it is entirely possible if
you ever start to really build out a micro services application that you're different services will
have different implementations.
So Ruby on Rails Java spring whatever else in addition to having different code or languages inside
these each of these services they also might have their own different databases different databases
to suit different needs for each service.
So right now on our off service we are making use of Mongo DB.
But you might be working on a service at some point the future.
The same exact project that instead uses my Eskew L or another one that uses Postgres.
So is there anything that's gonna come up as we start to look at using these different databases.
Any big issues perhaps.
Well there definitely is.
I want you to consider a very simple little funny thing.
So we are making use of Mongo D.B. Mongo has some very interesting semantics around the I.D. field Mongo
DV internally records the I.D. as underscore I.D. and you can even see that with the response we got
back inside of postmen.
We've got underscore I.D. right here that is the idea of this record Mongo TB is the only database out
of these three at least perhaps are others out there I want to say the only data base in the world but
out of these three it's the only database that uses those semantics reflecting the I.D. as underscore
I.D. my askew will pose a more typical standard of simply I.D..
Same thing with Postgres as well so why is this relevant.
Well it all goes back to our front end application.
Remember we spent a huge amount of time earlier on INSIDE THIS course dealing with making sure that
we always had very consistent error messages going back to whoever makes requests.
We need to make sure that the exact same is true as much as possible whenever we attempt to fetch normal
data as well.
So if I make a request to my all service orders or payments asking for just one record or trying to
sign up Rita order read a payment whatever it is I would expect on my front end to always get consistent
looking responses.
And that means that rather than having underscore I.D. right here which is very atypical in general
really we want to have simply I.D. And that's pretty much it.
That's what I'm making this big deal around.
We don't want to have these semantics that are very specific to Mongo DB.
Being exposed on our front end instead we want to have very consistent responses no matter what we are
making a request or which service we are making the request to that's pretty much it.
In addition to removing this password field and underscore underscore V we should also do a little bit
of reformatting on that key of underscore idea as well.
Now we can definitely take care of this very easily back inside of our sign up request handler.
So right here we could add in just a little bit of logic to just pull out say the email and the I.D.
reads a sign that I.D. property to a better key or something like that.
But there's really definitely a better way of handling this and making sure that we only have to worry
about this in one single location inside of our codebase rather than having to duplicate this I.D. remapping
logic and all that stuff inside of other root handlers like sign in or current user as well.
Now that we understand the issue let's fix this up in just a moment.