Wholesale Service

Ownership - B2B Team

Notion

Env	CICD state
staging
master

Description

A WholesaleOrder is a request to move products from Deliverr's Deep Storage into either

• Deliverr Fulfillment Network
• External Fulfillment Network
  • FBA
  • WALMART
  • Etc'
• Wholesale orders to external merchants.

This service uses TSOA And OpenApiGenerator in order to reduce the hussle envloved in documenting a production service that evolves with time please refer here for more information:

• Tech Talk - (Notion)
• Slack Channel(#documentation-as-code)

API

Auto generated openApi specifications can be found here

Event Driven Architecture - CDC Based

flowchart
	b2bDatabase[(B2B: WholesaleOrder, WholesaleShipment)] -- binlog file --> Kinesis
	subgraph wholesale-cdc-service
	Kinesis -- enqueue --> SQS-wholesale-cdc-queue
	end
	subgraph wholesale-service
    Lambda-getCdcUpdates -- dequeue --> SQS-wholesale-cdc-queue
    subgraph EventDecisionMaker
    -SHIPMENT_STATUS_CHANGED
    -FREIGHT_HAS_BEEN_ORDERED
    -PRO_NUMBER_RECEIVED
    end
    Lambda-getCdcUpdates --> EventDecisionMaker
    EventDecisionMaker --> SNS-WholesaleEvent
    SNS-WholesaleEvent -- event: type, payload --> SQS-WholesaleInternalEvents
    SQS-WholesaleInternalEvents -- process internal events --> Lambda
	end
	SNS-WholesaleEvent -- event: type, payload --> subscribers
	subgraph subscribers
	end

Development

One time setup

We use dev to manage dependencies and requirements.

You can run dev up and it should setup your development environment.

dev up will do the following tasks

• Setup your npmrc by getting the right credentials from AWS
• Install podman
• Install podman-compose
• Run the containers in the compose.yml file (Mysql, sqs, maxwell etc.)
• Install npm packages
• Run the migrations and get your db up to date

Before each run

dev up

choose a running script from here

Mimic Remote Environments locally

local-(prod|staging) | runs the service as it will run in prod/staging

(prod|staging)-localdb-local-auth | runs the service as it will run using prod/staging dependencies with a local database and all the rest of the environment parameters described in the .env file.

TSOA Based Auto generation

generate-sources script here will run multiple generations in sequence:

Routes

Using TSOA will generate the actuall Koa routes file based on TSOA decorated contollers

OpenApi Spec

Using TSOA will generate an update openApi file based on TSOA decorated contollers

Client

Using openApi generator CLI will generate a programmatic AXIOS client

• WholesaleClient is NOT GENERATED , it's an abstraction and new routes should be added there manually from the generated routes in the api folder*
• Generated code is local, it will be generated as a part of the cicd process

Debug in Visual Studio

• After the API has started
• Cmd+Shift+P choose "Debug: Attach to Node Process"
• Choose your process (the process name should start with "sls offline ...")
• Add a breakpoint in your code
• Call the API
• NOTE: If you have issue authenticating with basic auth please refer to the .env file with local values.

Build and pack the client

Client will be packed and released along the Wholesale service deployed to production. Client version should not be deployed otherwise as the client is generated from the service

testing

Team Testing Guidelines

Unit Testing

identification

Defined with a uspec suffix

how to run

npm run ustest

Integration Testing

identification

Defined with a ispec suffix

how to run

dev up
npm run itest
dev down

end-to-end tests

definition

tests that run in a separate process from the service, require a running service, local / remote and testing the flow without using any mocks, while using live external services

identification

Defined with a e2eSpec suffix

how to run locally.

Local e2e using prod external services.

dev up
npm run smoke-testing-server-prod-based
npm run e2etest-local
dev down

Local e2e using staging external services.

dev up
npm run smoke-testing-server-staging-based
npm run e2etest-local
dev down

how to run against a live env.

e2e testing supports running with multiple env's

one time action

npm run e2eBuildEnvFiles

this step needs to be repeated once, it will create env files with the relevant secrets DO NOT ADD TO GIT

Running E2E against live staging env

npm run e2etest-staging

Running E2E against live prod env

npm run e2etest-prod

Email notifications:

when interacting with the service using a test warehouse (TST)

All emails will be routed to a test email server with a suffix of the original email address.

Ethernal mail

Credentials:

user: "[e-mail]", password: "pQUwQAgU5N9bV29cqw",