============
Technologies
============
This section is intended to explain the technologies used in **The Sheriff**
to implement the **infrastructure** details of the application.
These tools are found within the *Infrastructure* layer
of the *Hexagonal Architecture*, and they have relation with other classes
located in the *Domain* layer. These relations are created by implementing
the defined **contracts**, and these are detailed in the last point
of this section. Besides, an impact analysis of what would happen
if a technology is switched by another one, in order to analyse
the modularity of the system.
GNU Make
--------
`GNU Make `_ helped the team not having
to deal with long commands and tooling details, through out the use of
few targets on the *Makefile*, found at the root of the project, the team
could easily run linting tests, unit tests, start the whole stack, etc.
Docker
------
`Docker `_ is used for delivery means. Docker
is a container runtime, that helped the team to have a cross-platform way
of running, testing and validating the application without the potential
problems of cross-platform development.
*The Sheriff* application is built as a container image that includes all
its dependencies and defines the command to start the application.
For the persistance of the application, MariaDB has been selected,
also used as a container, it didn't need any modification, just configuring.
*The Sheriff* container image is built using *Dockerfile.thesheriff* file,
found at the root of the repository.
For glueing both continers, `docker compose `_
was our tool of choice for its declarative approach and flexibility.
Docker compose allowed the team to configure both containers as a single stack,
declared in the *docker-compose.yml*.
*The Sheriff* configuration looks like:
.. image:: ../images/Docker.png
:scale: 50%
:align: center
:alt: Docker configuration
Docker and docker compose allows the application to have a huge modularity.
If anytime the client wants to change any configuration on the stack, it's just
a matter of changing settings in the *docker-compose.yml* file.
Summarizing, Docker has been chosen for:
- Its **modularity**.
- **Cross-platform** capabilities.
- Its **flexibility**.
In brief, both tools helped the team saving time in configuring the development
environment and deciding the delivery method.
Curl
----
Curl is an open source application used in command line or script
to interact with websites.
In *The Sheriff*, *curl* is used to interact with *Controllers*,
on the *Infrastructure* layer.
Curl lets the user to provide information and trigger the desired
application use case.
For example, to create an outlaw, the user should write in the command line:
$ curl localhost:5000/api//outlaw/ \\
-X POST --data @examples/json/create_outlaw.json \\
-H 'Content-Type: application/json'
This use case triggering will be done posting a concrete JSON contents
in the specified URL.
Summarizing, Curl has been chosen to:
- For easily **Allowing communication** between the **user**
and the **application** (specifically in this direction).
Python
------
Python is an open source programming language, friendly to use, easy to learn,
and extensible with a lot of available third-party libraries.
*The Sheriff* application has been programmed in *Python*.
Basically, it has been chosen mostly due to its *low learning curve*
and its wide range *third-party libraries*. The following sections detailed
the chosen third-party libraries and their use in the infrastructure package.
If at anytime the client desires to change this technology, the application
would be **very compromised**, at some point that we will have to change
all the logic of the application (including the whole
infrastructure implementation).
Flask
-----
Flask is a web application micro framework. Being *micro* it gives
the developer the freedom to choose the libraries desired to implement the
web-application without imposing much on the model or architecture.
In *The Sheriff, *Flask*, serves the purpose of implementing the controllers,
defining routes (or REST endpoints) through the concept of *Blueprints*,
so each domain entity has its own controller with its own set of routes,
getting the data, where needed, using JSON and posted using curl. From each
endpoint the associated use case/s are invoked and the use case flow starts.
Summarizing, Flask has been used for:
- *Blueprints* to define routes and the way to invoke use cases
with their required data.
- *Flask Responses* and *Requests* returned and dispatched
to control the flow in several endpoints.
- *Jsonify* to deliver JSON bodies, within the Response object,
back to the user interacting with an endpoint.
SQLAlchemy
----------
SQLAlchemy is a Python SQL toolkit. It allows the developer to use
in a friendly way the SQL database through persistence patterns.
In *The Sheriff*, it has let the application to persist all
the information dealt with in the domain entities.
SQLAlchemy has been used for:
- Ease of interacting with a SQL Database.
- Abstraction from the SQL engine itself, allowing to replace the engine
with just defining the appropriated connection string.
- Table creation, using its *MetaData* object, shared among all repositories,
allows to create relationships that are taken care for transparently.
Smtplib
-------
The smtplib module is an SMTP client implementation to send mails to any
Internet machine with an SMTP service. It uses RFC 821 (Simple Mail
Transfer Protocol) and RFC 1869 (SMTP Service Extensions).
In *The Sheriff* is the library used to send email notifications with
the information required for the application, according the use case
that triggers the action.
Contracts
---------
These aforementioned technologies are implemented in infrastructure
classes. These classes implement the *contracts* or interfaces defined
in the Domain layer.
Taking a look in the class diagram, it can be observed
all the contracts in *The Sheriff*.
.. image:: ../images/the_sheriff_class_diagram.png
:scale: 40%
:alt: Class diagram to show contracts
Zooming in to the Infrastructure layer, it can be seen
the implementation of these interfaces:
.. image:: ../images/the_sheriff_class_diagram_zoom_contracts.png
:scale: 70%
:align: center
:alt: Class diagram to show the implemented contracts
In conclusion, to fulfill all the actions contained, for example,
in the "XXXX_Raid" use case, the use case will lead to call
a method in the *RaidRepository* and implementation in found
in the *MySQLRaidRepository*.
And this conclusion can be extended for the rest of the classes
seen in the last diagram.
References
----------
* `Docker `_
* `Docker Compose `_
* `Curl `_
* `Smtplib `_
* `Python `_
* `Flask `_
* `SQLAlchemy `_
* `Smtplib `_