haleyga / fixinator Goto Github PK

Since a FIX engine is meant to extract as much performance as it can (...from javascript here, ha), consider refactoring try/catch blocks to a simple #validate call or #isValid check. This conflicts with #1 in that that issue considers whether or not to remove validation in favor of throwing exceptions.

Currently, fields are constructed without throwing errors. The user calls #validate on each object and catches errors at validation time. Consider refactoring such that fields are validated on construction, and errors are thrown immediately rather than waiting for an explicit #validate call.

This would force users to handle construction-time throws, but I believe this is more intuitive than a silent #new followed by an explicit #validate call.

Include an optional DB feature to store messages (both sent and received). MongoDB would make plenty of sense here. Perhaps the inclusion of clients or users would be helpful, too.

The engine is leveraging a #validate pattern to verify and validate all fields, messages, builders, etc. Rather than simply returning true/false (boolean), consider building up a list of errors and returning this list instead.

Motivation:

With a true/false approach, the first error will short-circuit the validation logic and only notify the user that an error occurred. By correcting issues one-by-one, multiple attempts could potentially be required to correct any issues. By building a list of errors, all problems will be surfaced at once. This would improve logging/database activity and also provide the user (including remote FIX engines) with more useful information the first time a validation error occurs.

A FIX engine must support the use of checksums to verify all messages:

• The message sender must calculate the checksum against the final, possibly encrypted, message prior to being sent
• The message parser must verify the checksum against the received message

Some FIX fields employ and quasi-enum type wherein a typical FIX Int or FIX Char is constrained to a list of acceptable values. I have changed how these are represented many times and need to settle.

My favorite (not yet fully implemented) method is to build an object with string keys and string values. The string keys will be constrained with a string union type.

Example:

export type ConstrainedKeyValueMap<U extends string> = { [K in U]: string; };

export type TestTypes = 'test1' | 'test2' | 'test3';

// The only acceptable keys are defined in the TestTypes union
export const TEST_TYPES: ConstrainedKeyValueMap<TestTypes> = {
    test1: 't1',
    test2: 'this is the value for test2 type'
    test3: '3'
}

Finish a complete FIX engine (parsing, sending, validation, etc.)

A FIX engine must support various encryption/decryption methods. This engine has not yet implemented any cryptography. Further, care must be taken regarding which fields can/should be encrypted in the first place.

While developing cryptographic functionality, ensure it it seamlessly integrated into message construction (both sending and parsing).

Implement a system-wide logging solution.