Hi!
Over the next few videos, we're creating a trivia question microservice from scratch,
end-to-end.
That means all the code, and all the infrastructure to build, test, deploy and run.
To start, this video is an road map for the microservice we're going to create.
It will give you an idea for all the technologies we'll use to create our microservice.
This tutorial demonstrates a way to create a microservice.
This isn't THE way.
There are many solutions to this problem, but hopefully this will give you enough direction
to start creating your own microservices.
These videos will also diverge from how other tutorials work on DeegeU.com.
Every video in this playlist builds on the previous video.
We're building something bigger, and we can't do it in one video.
Imagine we're creating an online trivia game.
The game will likely need to handle many tasks.
We'll need code to handle our users, code to get new questions, code to handle processing
answers, and probably several other functions not listed here.
Each function could map to it's own microservice.
To start, we'll focus on the trivia questions service.
What we learn from the trivia questions service can apply to any other services we need to
create later on down the road.
Our trivia question microservice will handle the trivia questions for our game.
Let's list out some of the use cases we'll need for our microservice.
The usecases matter because they describe the API we need to create.
For starters, we'll need to get a question.
This could be a particular question, or maybe we need a random question.
We'll do both.
We could expand this to get questions from a category, or other more complex use cases,
but we'll keep things simple for the tutorials.
We'll also want to be able to get the list of questions.
This will simply return the list of questions available.
We might have a million questions, so we won't return all of the questions at once.
We'll page the number of questions and keep it at a reasonable amount.
Our microservice API will also need to tell the user how to navigate forwards and backwards
in the list of questions.
We're going to put all of this inside a continuous integration process.
If we're constantly building and deploying our applications, we can easily lose track
of which version is running in production.
This means our microservice needs to be able to tell us which version is running.
We'll add a call that returns the version information for the microservice.
These calls will make up the API for our microservice.
Since I just mentioned continuous integration, lets talk about how that's going to look when
we're all set up.
Our continuous integration system will look like this.
We'll use a git repository to manage our version control.
In git, we'll add a trigger for when we issue a pull request to notify a build server to
build our code.
This will build our microservice, run our tests, package it up and store it in an artifact
manager, and then deploy it to production.
We need to make sure we have unit tests in place for our microservice.
These will protect us from deploying broken code.
Since we're storing every build in an artifact manager, we can roll back to previous versions
just in case we deploy something bad.
This all happens automatically, so that's why it's important we include testing and
version information in our microservice.
We need to know what is running, and what code was used to create it.
You can use almost any programming language to create microservices, but we're going to
use Java for these tutorials.
All of the concepts still apply for any language you use.
We'll use Maven to describe how to build our microservice.
If you're unfamiliar with Maven, you might want to check out the Maven playlist.
It's listed below.
Our trivia microservice will expose a REST API that returns trivia questions in a JSON
format.
Almost every language knows how to make HTTP calls and process JSON text.
We're going to implement our microservice using Wildfly Swarm.
That's a framework for creating Java microservices that can run independent of a Java EE container.
Technically, we're putting the JEE container inside our application.
If you're uncertain what a Java EE container is, that's ok.
The short story is in the past we ran web applications inside a web container like Wildfly
or Websphere.
That makes our microservices unnecessarily complicated, and we end up deploying much
more than just our application.
Wildfly Swarm hides all of this inside a jar.
At the end of the day, our application is just a jar, but we still get most of the benefits
of running in a Java EE container.
There's a bit more to that, but that's all we really need to know now.
Our microservice will be created in a Docker container.
This will ensure that what runs on our development machine matches what is deployed in production.
It will also make it very easy to provision more instances of our microservice as needed.
We will cover preparing our application to run in a container, and building the application
into a container.
Finally we need to deploy our Docker container to run somewhere.
We're going to run it on AWS, but you can configure your build to deploy to where ever
you run your Docker containers.
So hopefully this gives you a taste for everything we're going to cover.
It's pretty exciting!
We'll cover each topic in depth as we build our service.
If you have any questions, let me know.
For some of the bigger questions, I'll add them to the end of these tutorials.
You can find the code on GitHub, and the complete transcripts on DeegeU.com.