Now that we understand how Code 10 does all the stuff, we're going to apply the same kind of logic
and decide whether or not it is appropriate for the application we are building.
Let me give you a quick reminder on what we are trying to make here, because it's been a while since
we've really discussed the overall application that we're working on.
So as you may recall at the very start of this course, I gave you a quick demonstration for the book
application that we are ultimately trying to build.
So here are the series of steps we went through during that demonstration.
I had shown you that I want to build to run a command on my local machine of something like JDBC serve.
When I run that command, it should start up a local server on localhost at Port four thousand and five.
I was then able to open up my browser, navigate to localhost four thousand five.
I was then able to write out some code inside of a code editor.
That code was then bundled directly inside the browser and then just, you know, like the actual application
that I was running at that point time.
It was executing all that code inside of an iFrame.
No matter what, we are going to use an iFrame here.
It's just a really question of how that iFrame will be configured.
So the real thing we need to decide here, the real thing I want to just examine inside this video very
quickly, is whether or not you and I actually need some separation like this.
Do we actually need to serve up our react up from some domain and then serve out the contents of the
iFrame from a second domain?
Remember, the only reason or one of the only reasons that Copan Code Sandbox and all these other services
have this separation in domain names is to get that extra layer of security and make sure that whatever
code is running inside of that iFrame cannot affect the outside document or that parent document.
That's what these two different domain names are all about.
So we really have to decide whether or not we have to do that inside of our application.
Do we want to have our main react up that is going to show the overall notebook server from localhost
four thousand five and then maybe have some different domain name of something like localhost four thousand
six to serve up the content for the iFrame?
That is the big question we need to ask here.
The reason that we are asking ourselves this is that our application doesn't really have any authentication
mechanism.
We don't have any credentials that can be stolen like code, sandbox or code does.
There's not really any kind of malicious code that someone's going to run inside of one of our users
browsers that's going to cause any serious problems inside of our application.
In other words, I would not really worry about taking some other users code and running it directly
inside of our book application just because there are no credentials.
There's nothing like that that this is a standalone development environment.
So do we actually need these two different domains just for serving up the main react up and the iFrame?
I think that you could very easily say that no we don't, because we just don't have the same kind of
security issues.
So we could absolutely decide that for our application we're not going to use a flow like this.
Instead, we can decide to basically do everything from just one single domain if we wanted to.
But we're not going to do that.
We're not going to take the easy way out, even though we definitely could in our case, the reason
we are not going to take the easy way out and just serve up everything from the same domain is that
eventually we might decide that we've got a really neat application here and maybe we will want to allow
users to host all these different notebooks they put together online.
Maybe we would want to allow there to be some kind of authentication mechanism around getting access
to these notebooks or something like that.
So if we take the easy way out right now and just say, you know what, we're just going to serve up
the main app and the iFrame from the same domain and not worry about any of the security stuff, it
might come back and bite us later if we start to ever expand our application.
And at that point in time we would have to refactor everything to include all these different security
concerns.
So at the end of the day, even though we technically don't really need to worry about the security
stuff for our application, I think we should still address it nonetheless.
OK, so now we've got a better idea of what we are going to try to do here, the last thing I really
want to ask ourselves is whether or not we really need to serve everything up from different domains
or in this case, different ports, technically.
Or if there is some other kind of easier way that we can implement all this stuff and still have this
kind of security constraint satisfied as well.
So let's do just a little bit more investigation in the next video.