Skip to content

Instantly share code, notes, and snippets.

@hprobotic
Last active January 5, 2022 07:46
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save hprobotic/73682676b5971c4bd5c3fa85ed75f3c8 to your computer and use it in GitHub Desktop.
Save hprobotic/73682676b5971c4bd5c3fa85ed75f3c8 to your computer and use it in GitHub Desktop.

Reap Card

Backend of Reap Card application

Documentataion

EHI Doc: https://drive.google.com/file/d/1BTal4EezMka301bwAloNYiNHIn1oy1Eo/view?usp=sharing

Web service Doc: https://drive.google.com/drive/folders/1l3C8mIJvIdTBmZ2n8CrDGv6zbB5k89WL?usp=sharing

Flow charts: https://whimsical.com/reap-card-YJHEfJY7RagbjfXWtBzZzr

EHI notification mapping table: https://www.notion.so/reap/9189742fdd9d4efda8a2a426f74a1b1e?v=4976cfdd26ff4238aa94726da6607b75

EHI notification and how it affect balance: https://www.notion.so/reap/Balance-handling-for-different-type-of-messages-1cd52a747adc41ef96dfa7a9ae813e97

Idea and flow of statement generation: https://whimsical.com/dynamic-statement-period-PCt4CJgqcrQbb2R5K8MtHT

How to run

Locally:

yarn
docker-compose -f docker-compose.yml.development up

Dockerfile is used in production environment

DB migration

Can refer to the document here: https://typeorm.io/#/migrations

Common commands realted to migrations:

# To create a new Entity:
DB_HOST=127.0.0.1 yarn typeorm entity:create -n new-table

# To create a migration script after changed the entity:
DB_HOST=127.0.0.1 yarn typeorm migration:generate -n added-a-new-table

# To apply the migration to the DB:
DB_HOST=127.0.0.1 yarn typeorm migration:run

# To rollback the last migration:
DB_HOST=127.0.0.1 yarn typeorm migration:revert

Swagger and request data validation

We use swagger-ui-express to show the swagger doc and joi to do validation on the request body.

You can go to http://localhost:5678/api-docs in your local to access the Swagger UI.

For file defining the data schema, name it with {FEATURE}.schema.ts For file defining the api doc, name it with {FEATURE}.swagger.ts

Feature specific spec files should put inside the feature folder while shared spec files should be put inside src/common/swagger.schema.ts

In order to keep the doc and the actual validation always in sync, we used joi-to-swagger to manage the request body/params schema. Which can generate schema for both JOI to validate input and for Swagger to generate the api doc.

Whenever we defined a new spec for a new feature, we need to map that new spec file in src/swagger.def.ts

To validate the data passed in the request, import the schema in the route and call validateAsync to validate the data

You can automatically generate the corresponding type file from .schema.ts by running yarn schema, the generated type file will be located in the same file with extension .schema.type.ts.

src/
├─ features/
│  ├─ A_FEATURE/
│  │  ├─ A_FEATURE.swagger.ts
│  │  ├─ A_FEATURE.schema.ts
├─ common / common swagger definitions should sit here
│  ├─ swagger.ts
│  ├─ validator.schema.ts
├─ swagger.def.ts

Integration test

First create a test DB: docker-compose -f docker-compose.yml.development exec sql createdb test -U reapcard

Then you can run integration tests continuously by this command: yarn pre-integration-test && SLACK_TOKEN='' yarn integration-test

  • yarn pre-integration-test => Truncate and remove all tables then recreate all of them based on migration scripts
  • yarn integration-test => execute all the integration tests located at integrationTests/

Basic dea of Integration test:

  • Mock all the third party call, only test the business logic (Can verify by disconnect your wifi when running test)
  • Need to assert DB data changes if it affect DB

Folder structure

integrationTests/
├─ fixtures/
│  ├─ api/
│  │  ├─ API calls with mocked function, that can be used by other tests
│  ├─ entity/
│  │  ├─ fixture to create pseudo data in DB based on Entity
│  ├─ Other fixtures that can used by other tests
├─ test files / folders contains tests sit here

CI/CD flow

  • Checkout master branch [Master branch is only one source of truth now]
  • Create new feature branch base on master
  • Commit new changes to feature branch, create pr, request for review and deploy to staging manually
  • In case multiples pr is required for staging deployment, that's need to be group together in single pr and deploy to staging [But we try to prevent doing this]
  • Request Product team to do the QA, whenever that's fully QA-ed => merge code to master The pr checks trigger by the pr update describe bellow

Screenshot 2022-01-05 at 13 07 06

Deployment

  • To staging: We can deploy specific branch to staging by run the commands bellow
bash .helpers/deploy.sh <branch_name>

The command above will use your latest changes on the branch, update with master then deploy to staging reap card env

  • To Production:
  1. Checkout latest tag on remote
  2. Deploy tag to production by run:
eb deploy reap-card-prod --profile prod-card
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment