At this point,
we are getting closer to the end of this module.
We now also learned about multi-stage builds,
and we saw how we can deploy multiple containers,
not just on the same host,
in the same task in ECS' case,
but also on different hosts.
And I'm saying host,
because we have different domains
for these different deployed containers.
Now I also wanna verify
whether everything still works correctly locally.
With docker-compose up.
Because that, hopefully, should still work.
If I run this,
and I enter localhost 3000,
I still see my goals up there.
And I got no goals here
because we're using a different database in development.
But I can add goals, and they stick around
just in that development database.
So that also seems to work just fine,
and without any errors.
Which is good, and which is of course exactly what we want.
Now I also wanna talk about
having different Docker files for production and development
because at first, this might be strange.
After all,
one of the main reasons for using Docker
was that we have the same environment
in production and development.
And I wanna emphasize that we still have that.
Having the same environment
does not mean that there can't be differences
between production and development.
In React's example,
we need differences,
because the code needs to be optimized.
That's done automatically with a build script,
but therefore we need a separate image
that takes care about that build script
and builds our code,
before we serve it.
There is no way around that,
it's not a weakness in our setup,
it is what we need to do
for React projects.
Things like using different URLs here in our React code,
or different MONGODB database names,
for development and production
also are totally normal.
This does not change the way our code works,
and this does not change our environment.
This is still a React app,
and the backend is still executed with node.
These are just differences in our code,
which make a lot of sense.
After all, we don't want to work on the production database
when we're just testing our code.
So you shouldn't make the mistake of thinking that
just because there are some differences in code,
or because we take care about different scenarios,
like here with different backend URLs,
that this would mean that all of a sudden
we don't have that reproducibility.
We absolutely do have it,
because the code
and the environment is still locked
into an image and a container.
And even if we have different images
for development and production,
as we have it here with React,
we only have that because React forces us to do that.
But our code is still the same.
And React simply doesn't need any other environment tools,
it doesn't need node just to execute the code.
It just needs node to build the code,
and therefore we have code,
both in the development,
as well as in the production environment.
And of course we could use the exact same node version
in both Docker files,
if we really wanted to ensure
that we have the exact same setup.
So let's maybe do that here.
That's just something I wanted to emphasize,
because it's easy to get confused by that,
and to think that, well,
all of a sudden we're not using Docker's benefits anymore.
We definitely are.