We were just able to get some air messages inside a postman which means we're now doing some validation
of the incoming request.
Now this definitely all seems good but it also opens the door to a really interesting topic.
They're actually going to spend a lot of time on in this application and this is a topic that we have
not brushed upon or even discussed even remotely in the course so far.
Kind of an interesting thing overall.
So let me show you a quick diagram or two.
All right.
So here's what's going on inside of application right now or at least will be very shortly.
Right now we are making a request from postman not a react application.
Well let's just imagine for a second that we do build out that racked up so we will have our ReACT app
running inside our browser.
A user at some point time is going to attempt to sign up for an account and maybe they enter in an invalid
e-mail or they enter an invalid password whatever it is some kind of invalid data that's going to be
sent to our service or off service of course is currently working with express an actual validation
is being done with Express validator so because we are sending in some invalid data we get back a response
that has this kind of structure right here.
This is abbreviated but it's more or less the structure of what we just got back inside of our response.
So it's an array of objects each object has a value in as G short for message RAM and location.
If we had multiple properties that were invalid it would all be listed out inside of separate objects
inside this array.
And so you can see that's kind of the structure of the response we just got back.
Now really important note here we are only getting this structure of response.
In other words an array of objects with a message property a param and those other two because we are
using express validator the structure of response you see right here is not necessarily standard.
We're not following a standard express validator is not following a standard there's not some standard
out there were some documents out there online that says oh yeah this is how you need to send back some
list of validation errors instead someone who put together express validator said like the actual author
that library they sat down said you know what.
I think that this is a response that kind of makes sense to describe what just went wrong.
But this validation now the reason that is relevant is that we are in a micros services architecture
and remember at some point time we're going to have to start to introduce many other services into our
application so we might have an order service and a payment service as well.
The other thing that's really relevant is that these other services could be built using completely
different languages and frameworks.
So we are going to of course build everything inside of our app with express and express validator.
Well we could very easily imagine that if we were working on some professional project the order service
might be using some Ruby on Rails API and the payment service might be using Java spring so totally
different languages really different frameworks.
Chances are you know I don't know this off the top of my head but chances are that if we ever have our
ReACT application submit some invalid data to a ruby on rails at the ruby on rails app is probably gonna
give back some response that looks very different than the one that we just got back from Express validator
and same thing with Java spring as well if we submit some invalid data and Java spring does some validation
on that incoming request it might send back a response that looks even more different than the Ruby
on Rails one.
So what trying to say here is that in the micro services environment where we're going to have multiple
different languages multiple different frameworks running on all these different services whenever we
submit some invalid data to these different services we're going to get back a response that might have
a very different looking structure now quick question for you.
Is that a problem.
Is that an issue.
Well I'm going to say it is a tremendous issue I'm going to say that is a huge problem.
Here's why we are assuming that all these very different response structures are going to be going back
to the same exact react application.
So inside of our ReACT app we're going to have to encode the knowledge of how to work with these different
kinds of responses the react app is going to have to know that if it is making a request to the off
service it should respect a URL should expect a response that looks like this right here or in array
of objects but those exact properties the react app will also have to know that if it is making a request
of the order service it should expect a response that looks like that.
And same thing with this payment service down here as well so the engineers who are in charge of this
front end application are going to have to have a very in-depth knowledge of exactly what kind of air
structure they're going to get back from each of these very particular services.
And as you can guess that's not really a responsibility that we want to throw on the engineers.
We're building our ReACT application so as we start to build out all these different services we need
to make absolutely sure that every single one is going to send back a identical looking structure anytime
there is some error that occurs.
So we want to make sure that our ReACT app only has knowledge of how to pass exactly one kind of a response.
It should always be maybe an array of objects or just a simple object we can use any structure for this
a response that we want.
We just need to make sure that it is 100 percent consistent between all of our different services again.
So these react engineers don't have to understand that oh I'm making a request to my art service I should
expect some kind of a response it looks like that versus something totally different.
So as I mentioned at the start of this video we're actually spend a lot of time in this course to make
sure that we've got extremely consistent error structures.
Any time we make a request to any of our different services this will be a lot easier than it sounds.
Mostly because remember we're going to end up creating that shared library that has a lot of code that
we're gonna share between all of our different services and that's how we're gonna make this approach
of handling errors rather easy and straightforward okay.
So with all that in mind because we're here we're going to start doing some further work on our validation
and the response in just a moment.