==================================
First Microservice
==================================

Introduction
-------------

Microservices are the modern solution to problems from the past. Which problems? Well. Most applications made prior to 2010-2015 are Monolithic. Before being able to answer why my project needs to use Microservices, we first need to understand why microservices are a vital part of the modern software stack.  

Theory
----------

What is a Monolith, and why is it bad? 

Even though your application may use a variety of standard design patterns, such as MVC, SOLID, etc. it may still be a monolith; a monolith typically is a **single** application in which all of its components can be consumed. Why is this problematic? During the turn of the century, the internet has become a massive part of our society. We must make applications that can handle a lot of users; and a typical disadvantage for a monolithic application is its scalability. Lets say you have a banking application, and the most used function is when an user checks their balance. Scaling this application means that components that are used way less also scale up. 

Cloud has become a bigger part of the internet; for simple reasons, you want high availability and connectivity throughout the world; as your application may be used in the Netherlands, or in Australia. The biggest disadvantage that the Cloud (AWS, Azure, Akamai, etc.) all face are the costs. Thus, cutting down your application into multiple services means that this cost will not grow exponentially despite only one component being used often. 

Thus, most Enterprise applications use a variety of Microservices, which still accomplishes the same thing as before--but with a focus towards the resources used in order to host the application.

What is stateful and why is it a problem? 

Another problem that this microservice setup introduces is that applications can be stateful or stateless. Before I can explain why this is a problem, you first need to understand what these terms mean. A stateful application contains static information in order to make the application run. E.g. having *login=true* in your code. This is a problem in the Microservice scaleability; since a microservice might scale-up, but the second instance of the application may not recognize the *login=true* and this will throw problems in production. 

The solution to this is making the Microservices stateless. 


Execution
----------

I created my first Microservice for the User component. This microservice uses mySQL; for simplicity reasons & the user microservice being a lesser used component in my application. I used my previous Spring Java REST API codebase to quickly set it up. 

Implementation
---------------

I created the multi-folder application using SOLID methodologies and using a collection as a list of Accounts. Here is an image which properly lays this out:

.. image:: https://i.imgur.com/3N0gEJn.png

The SpringServer class serves the REST API. In my resources I have a data.sql file which fills the database up with a few example records I can use to test simply test with. 

Validation
-----------

Running this Microservice locally works, and the result can be seen here:

.. image:: https://i.imgur.com/UGg3bqb.png

The API returns a RESTful HateOAS Level 3 Maturity call. What makes it level 3? From my understanding, it is mostly about sending links back which are supported operations. I created an addition to have pwreset as an option, to demonstrate that the API is mature.