Level 1

Product

• KakaoTalk Chatbot Channel Link

APIs

• Product https://product.lapiki-invest.com/docs
• Market https://market.lapiki-invest.com/docs (documents only)
• Market-Child https://child.lapiki-invest.com/docs (documents only)

---

---

Stack

NodeJS (18.12.1) / Typescript / NestJS
PostgreSQL / typeorm
MongoDB Atlas / mongoose
cache-manager / Redis / node-redis
fxts / rxjs
jest
child_process / cron

AWS EC2 / Nginx
Docker / pm2 (will be deprecated)

Python (3.8) / Fastapi / uvicorn
yfinance / exchange_calendars

---

Test

[CAUTION]
npm, docker compose(V2) should be available.
docker daemon should be running.
Local Port 5432, 6379, 27017 should be available.

• Todo: use test containers and port

# First, Install all the dependencies
$ sh scripts/npm:install

$ sh scripts/test

---

Run

[CAUTION]
cURL should be available.

$ sh scripts/pfa:start

 The scope of serviceable assets and exchanges in this app is expandable and sustainable throughout multiple lifecycles of the app.

 At the start, the app does not follow any exchanges, which means there is no update schedule for any exchange. Also, the app does not possess any information about any assets.

The initial service scope of this app is 0.

---

APIs

Here are three servers running.
The Market server focuses on updating and managing market data.
The Product server directly serves data.
The Market-Child is just a server dependent on the market server.

• Product http://localhost:7001/docs

• Market http://localhost:6001/docs

• Market-Child http://localhost:8001/docs

---

 When something is queried, the app fetches data about that asset from the market and creates it. It also identifies the exchange to which the asset belongs and starts following it. This implies having an update schedule for that exchange and updating data according to the exchange's session on a daily basis.

The service scope expands through queries.

 From now on, even if the app loses the update schedule for all exchanges due to being shut down, it can independently generate schedules for the exchanges it is following.

 Upon relaunching the app, during the initialization phase before listening, it explores the sessions of exchanges and creates schedules. It also update assets belonging to each exchange if necessary.

---

Logs, Monit

Use below,

$ docker [OPT] logs [CONTAINER]

OR

$ sh scripts/pfa:[EXCUTION]:[SERVER] [LINES]

• EXCUTION: 아래 중 택 1 필수
  • logs
  • monit

• SERVER: 아래 중 택 1 필수
  • product
  • market
  • market-child
    • EXCUTION = monit 인 경우 선택 불가능

• LINES: number
  • EXCUTION = logs 인 경우에 선택적으로 전달 (기본값: 50)

---

Reload (0 downtime)

[limitations] Using pm2 in each containers

# Product Server (pm2 in container)
$ sh scripts/pfa:reload:product-pm2

# Market Server (pm2 in container)
$ sh scripts/pfa:reload:market-pm2

---

 So far, I have explained how the scope of serviceable assets and exchanges in the app can expand and be sustainable.

This design approach has two main goals:

1. Optimizing server resources.
2. Maximizing performance.

 Market data is extensive. Therefore, the server dynamically determines the range of resources to manage based on user requests. Consequently, if a user requests resources beyond this range, they will experience relatively slower responses. However, subsequent requests for those resources will be served from the in-memory database of the server, ensuring high performance. The in-memory database is continually managed based on exchange sessions and user requests.

Details

The following is a sequence diagram showing the initialization to the listen phase of the market server.

[should be updated]

...more

---

Clear all about this project

[CAUTION]
down and remove all containers and images about pfa.

$ sh scripts/pfa:clear

if you just want to stop or down all pfa containers,

# stop
$ sh scripts/pfa:stop:all

# down
$ sh scripts/pfa:down:all

---

Deploy

RDS Certificate

cert/aws-rds.pem

Compose .env files

env/.env.market.guide.production
env/.env.product.guide.production

Then,

$ sh scripts/pfa:start:prod

Migrations

# typeorm Migrations dir
market/migrations/
product/migrations/

PostgreSQL

각 컨테이너 내부에서 typeorm 이용. (migration 관리 가능한 admin 있으면 편할것같음)

Migration 과 앱리로드가 필요한 경우, Migration -> 앱 리로드 순서로 진행해야 안정적임.
현 상태에서는 이것을 매끄럽게 하려면 귀찮은 일들이 있음. 이를 매끄럽게 가능하도록 시스템화 할 필요가 있음.
자세한 내용은 별도 Migration 문서에서 다룸.

Monitoring

AWS CloudWatch

CloudWatch Agent

# config.json 파일을 초기화하고 도커 컨테이너 로그파일의 위치를 추적하여 cwagent 를 재시작함.
$ sh scripts/cwagent:restart

---

---

Market

Modules

[should be updated]

Instances

[should be updated]