API

find(maker?, taker?, makerAsset?, takerAsset?, makerAmount?, takerAmount?): Deal[]

Mocha seems proper.

I added makerAddress field into order's DB model for keeping track of who made an order.

• Interface layout #14
  -web
  -responsive mobile; stack moving
  Divide the space of the screen and set the layout when it is converted to mobile screen

• Concept #15
  -font, color, shape, motif
  Set the look and feel of DEX

• Order book UI #16
  -element list up
  -list layout/concept (~12/10)

• Buy sell tab
  -tab UI

• Open orders/closed orders
  -tab/list UI setting (~12/12) #17

• Market tab #18
  -element list up
  -dropdown menu/layout design (~12/14)

• Component guide #19
  -text guide
  -component set(normal, selected, hover, disabled, etc) (~12/15)

• Chart #20
  -researching demo
  -fixing function
  -design (~12/19)

• Summary
  -error case, codex Logo, etc (~12/24)

-researching Highchart demo
-fixing function
-design (~12/19)

-element list up
-dropdown menu/layout design (~12/14)

yarn test doesn't work.

TSError: ⨯ Unable to compile TypeScript:
server/engine/test/engine.test.ts(5,25): error TS2307: Cannot find module '../../config/dex.json'.

-text guide
-component set(normal, selected, hover, disabled, etc) (~12/17)

mobile; stack moving
Divide the space of the screen and set the layout when it is converted to mobile screen

Strategy:

As a client submit its order, the relayer checks if there is a matching order stored in the order book. Before this, the relayer also checks if the order conforms with fee policy regulated by the DEX. Only the relayer can fill the orders so that there is no primary race condition from the matching process. The relayer also knows when orders are matched before anyone else and can update the order book as soon as the transaction is submitted.

Rest API

submit(inputs: assetTransferInput[], order: Order, marketId: number, makerAddress: string)

Check if the transaction is valid

Before relaying transactions, they have to be checked validity. First, the DEX have to verify that the transaction 's unlock script is valid. It means that the transaction has to provide a correct signature over order. After the validity checking is finished, the transaction will be relayed on the DEX so that other clients can fill the transaction.

Matching

When the transaction arrives at the DEX, there may or may not be combinable orders. If there are not, the transaction will directly go into the order book as order. The case becomes more complicated if there are orders which are combinable with the incoming transaction. It can be divided into three situations.

• There is an order which has exactly the same rate and amount with the incoming transaction - In this case, the order is filled and transmitted to a Codechain node
• There is an order which has the same rate but less amount than an incoming transaction - Fill the order and relay the remainder.
• There is an order which has the same rate but more amount than an incoming transaction - Do the partial fill

Matching priority

First In, Frist Match rule

Sync

All of the operations with DB have to be atomic. In addition, the matching processes have to be synchronized since matching only occurs in the DEX.

Buy sell tab
-tab UI

Open orders/closed orders
-tab/list UI setting

CODEX order watcher is similar to 0x order watcher

• The OrderWatcher is a daemon. You can start and stop it from subscribing to order state changes, add orders you would like to track and remove orders that are no longer relevant. Just can add order and get an event if the status of the order is changed.
• Once the OrderWatcher is started and an order has been added to it, it will emit events once, if there is a change in the state backing an order's fillability. If orderWatcher gets an event than it removes an order from the order book.
• There are two kinds of watchers in the order watcher. One is invalidWatcher which check the validity of orders except for expiration time. Another one is expirationWatcher which check an expiration time of order. The difference between them is the length of the checking time interval. The expirationWatcher's time interval will be much shorter than the orderWatcher.
• The orderWatcher will be managed by just list and the expirationWatcher will be managed by a min-heap. Therefore the expirationWatcher only need to monitor one order, which has a minimum expiration time.

API

// orderWatcher
addOrder(order):  void
// expirationWatcher
addOrder(order, expiration): void

• submit order #7
• get order book #8
• cancel order #9
• get my order #10
• get my completed order history #11
• log all request from a client: Use morgan #12
• order watcher #13
• redesign the order matching specification

A back-end of the DEX should be able to relay orders and keep them until the taker who wants to fill or partially fill the order appears. We need a model for orders which will be referred to an order book.

Order
  makerAsset: String,
  takerAsset: String,
  amount: Bigint,
  rate: Double,
  makerAddress: String,
  assetList: JSON
  order: JSON
  marketId: number

Except for the transaction field, other fields are only for querying transaction. These are also in the transaction.
Also, a model for the history of completed transactions is needed for future reference.

Deal
  maker: String,
  taker: String,
  makerAsset: String,
  takerAsset: String,
  makerAmount: Integer,
  takerAmount: Integer,

DB have to be changed according to changed matching scheme

By using TypeScript with Mocha and Istanbul

The Morgan library which is request logger middleware for node.js seems good to use.
https://github.com/expressjs/morgan
Recorded logs will be stored in /log directory per day

• find(field) - find order by given field
• getOrderBook(range: number, marketPrice: number) - get range number of orders which is placed up or down side on the basis of the market price.