-: In the last section,
we started talking about the application
that we're going to build to learn more about
multi-container deployments.
In this section, we'll continue by talking about
the backend architecture that we're going to use
to implement this application.
All right, so here we go, here's the backend.
Now, like I said, this is just over the top,
complicated, way more complicated than it needs to be
by like a factor of 20,
but I'm showing you this much more complicated backend
just to give you an idea of how we can take
these multiple containers, or multiple components,
and fit them together into one application.
Now this right here is a diagram of the development flow,
or the development architecture of our application.
So when we eventually push this
into a production deployment,
some of these pieces in here are gonna change
just a little bit
but I'll be sure to tell you exactly
about exactly how they are going to change.
So when a user boots up their browser
and tries to visit our application,
they're gonna first visit an Nginx web server
very similar to the one we had previously.
The Nginx server is going to essentially do some routing.
This server is going to decide whether the browser
is trying to access a React application,
to get some front end assets like the HTML file,
or some JavaScript file,
that will be used to build this application.
If the browser is trying to access some front end assets
like an HTML file or a JavaScript file
it will automatically route the incoming request
to a running React server.
If the incoming request is instead trying
to access some backend API,
that we are going to use for submitting numbers
and reading numbers and retrieving values,
all that kind of good stuff,
then the Nginx server right here will instead route
the request to a Express server.
So this Express server here is gonna function
as our API that's gonna serve up information
or calculated values up to the front end application.
Now let me show you a couple more diagrams
that's going to better explain this process right here.
So you might have noticed that on the last diagram,
we had these worker, Redis and Postgres things over here.
Remember that Redis is an in-memory data store,
and it's very commonly used for housing temporary
or kind of cached values of sorts.
I've also got Postgres right here,
which is a database very similar to say MySQL.
So you might have noticed
that in our web application mockup,
we had kind of these two sets of values right here.
We had first values that the application has seen,
or essentially values that have been submitted
to the application.
All of the information for this values I have seen
is going to be stored in a Postgres database.
And so you can kind of imagine
that values I have seen right here,
or really indices I've seen,
is a very permanent stored set of data,
all coming from Postgres.
On the other hand,
the calculated values that are going to be displayed
right here
all this information is going to be displayed
in a separate Redis database instead.
So again, we're just making this over the top complicated,
way more complicated than it has to be.
We have essentially identical data on the screen right here,
but we're just going to arbitrarily say that,
oh yeah, this source of data is coming from Postgres,
this source of data is coming from Redis over here.
Again, we're just doing that to make this
a little bit more complicated
and show you how you would work with these
different sources of data in a single application.
Now, lemme show you a flow of how our application
is really going to behave behind the scenes.
So let's imagine that a user submits a number
to the React application.
Like let's say they put a number into the form right here
and then click the submit button.
So when a user clicks on that submit button,
the React app is going to make a API request, or excuse me,
an Ajax request to the backend Express server.
The Express server, when it receives this number,
that it needs to calculate a Fibonacci number for,
it's gonna first take that number,
and store it inside of our Postgres database.
'Cause remember, that's gonna have a permanent list
of all the indices that have ever been submitted
to our application.
At the same time,
the Express server is also gonna take that index,
and put it into the Redis database as well.
When a new number shows up inside of our Redis database,
it's gonna wake up a separate backend Node.js process,
that we're going to refer to as the worker.
The only job this worker right here is to watch Redis
for new indices that show up.
Anytime a new index shows up inside of Redis,
the worker is going to pull that value out,
it will calculate the appropriate Fibonacci value for it,
it'll take that calculated value,
and then put it back into Redis,
so that it can then be requested by the React application
and eventually show up on the screen.
So again, over the top complicated, I can't say it enough,
I don't think you would end up building a Redis,
or excuse me, a Fibonacci calculator application
with this type of flow right here,
this type of architecture.
But again, I just wanted to show you
a multi-container deployment.
So now that we've got a better idea of how all this works,
let's take a quick pause.
We're gonna come back the next section
and we'll start putting this application together
from scratch.
So a quick break, and I'll see you in just a minute.