## CRUD Master

### Instructions

APIs are a very common and convenient way to deploy services in a modular way.
In this exercise we will create a simple API infrastructure, having an API Gateway connected with two other APIs.
Those two APIs will in turn get data from two distinct databases.
The communication between APIs will be done by using HTTP and message queuing systems.
All those services will be in turn encapsulated in different virtual machines.

#### General overview

We will setup a movie streaming platform, where one API (`inventory`) will have information on the movies available and another one (`orders`) will process the payments.

The API gateway will communicate in HTTP with `inventory` and using RabbitMQ for `orders`.

In this exercise you will need to install Node.js (with Express, Sequelize and other packages), PostgreSQL and RabbitMQ.

While it may seems overwhelming at first there is a lot of resources available both on official website and on community blogs about setting up those tools.
Also the specific configuration details may change from platform to platform so don't hesitate to play around with it and be sure to check everything is installed correctly before to move on.

#### API 1: Inventory

##### Definition of the API

This API will be a CRUD (Create, Read, Update, Delete) RESTful API.
It will use a PostgreSQL database.
It will provide information about the movies present in the inventory and allow users to do basic operations on it.

A common way to do so is to use Express (TODO add a link?) which is a popular Node.js web framework.
We will couple it with Sequelize (TODO add a link?), an ORM (TODO add a link?) which will abstract and simplify the interactions between our API and the database.

Here are the endpoints with the possible HTTP requests:

- `/movies`: GET, POST, DELETE
- `/movies/:id`: GET, PUT, DELETE

Some details about each one of them:

- `GET /movies` retrieve all the movies.
- `GET /movies?title=[name]` retrieve all the movies with `name` in the title.
- `POST /movies` create a new product entry.
- `DELETE /movies` delete all movies in the database.

- `GET /movies/:id` retrieve a single movie by `id`.
- `PUT /movies/:id` update a single movie by `id`.
- `DELETE /movies/:id` delete a single movie by `id`.

- `GET /movies/available` retrieve all available the movies.

The API should work on `http://localhost:8080/`.

(TODO add a link on how to setup it?)

##### Defining the Database

The database will done with PostgreSQL and it will be called `movies`.
Each movie will have the following columns:

- `id`: autogenerated unique identifier.
- `title`: the title of the movie.
- `description`: the description of the movie.

(TODO add link on how to setup it?)

##### Testing the API

In order to test the correctness of your API you should use Postman (TODO add a link?). You could create one or more tests for every endpoint and then export the configuration so you will be able to reproduce the tests on different machines easily.

#### API 2: Orders

#### The API Gateway

The Gateway will be the only service accessible by the user, it will take care of routing the requests to the appropriate API using the right protocol (it could be HTTP for API1 or RabbitMQ for API2).

The API Gateway should work on `http://localhost:3000/`.

##### Interfacing with API1

The gateway will route all requests to `/api/movies` at the API1, without any need to check the information passed through it.
It will return the exact response received by the API1.

In order to achieve this goal it will be necessary to setup a proxy system.
You could check `http-proxy-middleware` npm package in order to achieve such goal.

##### Interfacing with API2

The gateway will receive POST requests from `api/orders` and send a message using RabbitMQ in a queue called `task_queue`.
The content of the message will be the POST request body stringified with `JSON.stringify`.

##### Documenting the API

Good documentation is a very critical feature of every API. By design the APIs are meant for others to use, so there have been very good efforts to create standard and easy to implement ways to document it.

As an introduction to the art of great documentation you must create an OpenAPI documentation file for the API Gateway. There is many different ways to do so, a good start could be using SwaggerHub (TODO add a link?) with at least a meaningful description for each endpoint. Feel free to implement any further and more complex feature.

#### Overall file structure

You can organize your internal file structure as you prefer. That said here is a common way to structure this kind of projects that may help you:

```console
.
├── inventory
│   ├── app
│   │   ├── config
│   │   ├── controllers
│   │   ├── models
│   │   └── routes
│   ├── node_modules
│   ├── package.json
│   ├── package-lock.json
│   └── server.js
├── orders
│   ├── app
│   │   ├── config
│   │   ├── controllers
│   │   └── models
│   ├── node_modules
│   ├── package.json
│   ├── package-lock.json
│   └── server.js
└── api-gateway
    ├── node_modules
    ├── package.json
    ├── package-lock.json
    ├── proxy.js
    ├── routes.js
    └── server.js
```

You should be able to start the API Gateway and the two APIs by using the command `node server.js` inside their respective directories.

The Gateway should be able to send messages to the API2 even if that API is not running. When the API2 will be started it should be able to process that message and send an acknowledgement back.