Simple bank aggregator built with Node.js using TypeScript.
Simple bank aggregator built with Node.js using TypeScript.
You can install it using Node.js installed in your machine or by using Docker.
Git clone this repository
git clone https://github.com/Guilospanck/pyyne-bank-aggregator.git
and then cd into it
cd /pyyne-bank-aggregator
Run Yarn to install dependencies
yarn
Then run:
yarn start:dev
To start up the server.
With Docker and Docker Compose installed, cd
into the project directory and run:
# docker compose v1
sudo docker-compose -f docker-compose.yml up -d --build
# docker compose v2
sudo docker compose -f docker-compose.prod.yml up -d --build
In order to view the logs once it's built, run:
sudo docker ps # get the id of the container
sudo docker logs [id]
Once the server is started, you can test it by sending GET
commands to http://localhost:4444/
.
bank/transactions
This endpoint will retrieve transactions from banks registered.
bank/balances
This endpoint will retrieve balances from banks registered.
Inside the /docs
folder resides the Insomnia .json file if you wanna use it. Just import it in your insomnia and make requests.
You can also make the requests using curl
:
curl localhost:4444/bank/balances
curl localhost:4444/bank/transactions
To run tests, you can run the coverage command:
yarn test-cov
I'm using Clean Code Architecture for this project. The reason is because it provides a nicer and better way of changing and maintening the code, besides providing us the best out of design patterns and S.O.L.I.D. principles.
The goal is to have the code at the best readability possible and to have layers detached from each other. We must not be a slave to some library, some outside module or to some other part of our code.
Below we have the architectural names used for this project and their basic explanations.
.
├── applications
│ ├── errors
│ ├── interfaces
│ └── usecases
├── business
│ ├── dtos
│ ├── entities
│ ├── errors
│ └── usecases
├── infrastructure
│ ├── Bank1
│ ├── Bank2
│ ├── adapters
│ ├── http_server
│ └── repositories
├── interfaces
│ ├── controllers
│ └── middlewares
├── mocks
├── routes
└── shared
└── utils
Applications: this layer is used for usecases rules. What we mean by that is that here lies all business cases related to the project. If an outsider look at our usecases, they must know what our project does even though they don't undestand it. So, for example, we have inside of User the signin and signup usecases. An outsider will know that the User part of our project lies on getting a user signed in and signed up.
Business: here we have all things related to our intrinsic company needs. In here we define the I/O structures, the entities for the databases and so on.
Infrastructure: basically everything related to the outside lies here: a module (like express, typeorm, logger
) and a database (like postgres
). This is the part of our application that is using something external.
Interfaces: this is our front door of the application. All requests will be redirected to this layer before it takes time into the interior of our project. He is the frontman that gives directions for the requests coming.
Mocks: basically used for testing purposes. Here we'll have dummy mocked requests, objects, functions, classes in order to execute our unit tests.
Routes: as the name describes, all our endpoints are located here.
Shared: finally, this is the layer where we have something that can be used throughout the application, something that more than one layer will use.