stori-candidate

A repo with the challenge for Stori Software Engineer position

The code stored in this repo has been tested (Applying units tests), the arrow icon at the top of the repo means that all tests passed successfully

Here the coverage for api and db modules:

Instructions to run the project locally

NOTE: It's necessary first to have installed docker in your machine

1. Clone this repo in your computer

2. Go to the root folder of the project: cd stori-candidate

3. In the terminal type this command: docker compose up

4. The step number three will create two docker images (One for the stori project and other for postgres)

5. If all goes well, it will be possible to see the log with the init for gin

6. Also if you open other terminal and type this: docker ps, it will be possible to see the containers running for the stori project (NOTE: Don't close the terminal where you ran the docker compose up command, otherwise, the app will be terminated)

7. The app is running on localhost:8282, the all endpoints will be explained in detail in next steps in this README, however, You can take a look at the swagger documentation available typing this URL in your browser: http://localhost:8282/swagger/index.html, there, it will be possible to see the endpoints for the system and their parameters and descriptions

Brief technical description of the system

Database

It's used a postgres db in order to store the account and transaction entities, you can find the diagram inside the project in files/DB_Diagram.pdf and it looks like this:

An account is necessary to be availabe to create a transaction, that means We need to create an account before and then with the ID of that account we can create one or more transactions

Fields for Account:

Fields for Transaction:

Technology stack

This is the technology stack used:

Golang

• Golang 1.21
• Gin gonic as web framework
• Testify and faker for unit tests
• Sqlc to generate DB models
• Mockgen to generate mocks interfaces for email and db
• Swaggo to launch swagger documentation
• Viper to handle config env vars

General

• Docker 20.10.12
• Lambda functions AWS
• S3
• API Gateway
• Aurora RDS
• Postgres

Consuming API endpoints

Here the Postman collection to consume the endpoints locally through localhost:8282

sendSummaryInfoByFile

The easiest endpoint to consume is sendSummaryInfoByFile because it's not necessary to create previously an account nor a transaction, this endpoint can read two possible files ./files/txns.csv, ./files/txns2.csv

Input:

./files/txns.csv

Expected outcome:

Got outcome:

An email sent to the customer

Reading the second file

Input:

./files/txns2.csv

{
        "id": 0,
        "account_id": 0,
        "date": "1/15",
        "transaction": 70.5
    },
    {
        "id": 1,
        "account_id": 0,
        "date": "7/28",
        "transaction": -10.3
    },
    {
        "id": 2,
        "account_id": 0,
        "date": "2/02",
        "transaction": -20.46
    },
    {
        "id": 3,
        "account_id": 0,
        "date": "8/13",
        "transaction": 10
    },
    {
        "id": 4,
        "account_id": 0,
        "date": "1/13",
        "transaction": -10
    },
    {
        "id": 5,
        "account_id": 0,
        "date": "7/20",
        "transaction": 15.9
    }

Expected outcome:

Got outcome:

An email sent to the customer

createAccount

Input:

Outcome:

getAccount

Input:

Outcome:

createTransaction

Input:

Outcome:

getTransaction

Input:

Outcome:

sendSummaryInfoByDB

Input:

Expected outcome:

Got outcome:

An email sent to the customer

Consuming API endpoints through AWS

Before showing the consumption of the endpoints I would like to explain a little bit the AWS structure used for this project:

The common use case using the infrastructure of AWS in this project:

Our API gateway looks like this:

Our lambda functions like this:

Now it's time to explain the endpoints!

Here the Postman collection to consume the endpoints on AWS https://vj33odq2ta.execute-api.us-east-2.amazonaws.com/dev

Let's make this section short because We have explained before the all available endpoints in the system, here We are going to explain only sendSummaryInfoByDB (Summary made taking the transactions in DB) and sendSummaryInfoByFile (Summary made taking the transactions from the CSV file):

sendSummaryInfoByFile

The easiest endpoint to consume is sendSummaryInfoByFile because it's not necessary to create previously an account nor a transaction, this endpoint can read two possible files ./files/txns.csv, ./files/txns2.csv

Input:

./files/txns.csv

Expected outcome:

Got outcome:

An email sent to the customer

sendSummaryInfoByDB

Input:

Expected outcome:

Got outcome:

An email sent to the customer

---

Thanks a lot for your time reviewing this project!, any doubt feel free to reach out to me:

email: jdamianjm@gmail.com

phone: 22 23 16 81 67