Now for this module,
I got another demo application which you find attached.
And this application actually consists
of three different back end APIs which will work together.
Three different containers in the end.
it's a Node.js application
and you can definitely dive into the code.
But it will just be a dummy application.
We have this auth API,
which in the end is dealing with verifying tokens
and generating tokens for authenticated users.
We got the users API,
which is dealing with creating users and logging users in
and all of that happens in a dummy mode.
I'm not using a database here,
I'm not storing data in files,
we're just working with dummy data which is not stored.
Because this module is not about storing data.
It's about connecting these different services.
And indeed this user is API
will eventually reach out to this auth service here,
to for example, get this token
which is generated when a user is logging in for example.
And then we get this tasks API,
it's another very straightforward Node.js application.
And in there, we basically can return a list
of stored tasks and we can store a new task.
And indeed, this will be stored in a file,
which still only acts as a dummy storage Of course.
A database would be a better storage in reality
but again it's not about the storage.
But instead this API also actually will receive
a token, which identifies a logged in user.
And therefore it will also reach out
to this auth API to verify this token.
So here's the general structure of our demo application.
We have these free Node.js APIs,
which will be in a cluster.
And the users API for example,
talks to the auth API.
When we send the request to the users API
to create a new user,
the users API will talk to the auth API
to generate a token for that user.
These two containers the auth and users API,
each runs in their own container
will actually be created in the same pod.
At least at the beginning of this course module.
And we'll have pod-internal communication here
because the auth API will actually
not be reached from outside the cluster
but only from inside that first pod.
And the tasks API will run in another pod.
And both pods will actually be reachable
from the outside world.
But as I just mentioned,
the auth API will actually not directly be reached,
it will not directly handle the requests
from the outside world.
Instead, only the users API will
and will have this pod-internal communication
in that pod then.
Now this will not be the final picture
we're going to refine it throughout this module.
But that's what we're going to start with
and actually, I'm going to start with an even simpler setup.
I just wanna start with the users API,
for the moment not communicate with the auth API
and just ensure that the users API is able
to handle incoming requests.
Now before we translate this into Kubernetes,
you can absolutely play around with this API
because I do provide Docker files
and a Docker compose file already.
So of course you can run Docker compose up -d --build
and this application will be built
the images will be built
and these free containers will be startup.
And all the code should already work then.
And you could then use postman to send the request
to localhost 8080/login for example,
with some dummy email and password body data.
And that would reach the users API
which is listening on this port 8080
and that's the port I mapping here
in the Docker compose file too
and then for the log in requests which are just sent here.
This will then indeed,
extract email and password briefly verify it
in a very simple way.
And then reach out to the auth API
to actually send my password there
and a hashed version of the password
of course just using some dummy hashing data.
And then we'll get back a token
which is actually sent back with the response
and that's the token you see here in the response.
Now you can also try sending a request
to the auth API directly and this will fail
because it's not exposed publicly in this setup,
only other containers are able to talk to it.
And you can try fetching tasks initially that fails
but if you do store a new task by sending a post request
to localhost 80/tasks with a body
that contains a text and a title.
If you do that then this task will be stored
and there after if you send a get request
to localhost 8002 tasks
you can see that task here.
Now whenever you run Docker compose down,
all the data will be lost
because I'm not using volumes here.
Because again, the data storage
is not the thing I wanna focus on here.
Instead it's the container and service interaction.
Now Feel free to dive deeper into the code
and play around with that a little bit.
But for the moment, I will actually not do that.
I will run Docker compose down
because of course I don't wanna use Docker compose here
instead the goal is to use Kubernetes.
And that's what we're going to get started
with in the next lecture therefore.