sradevski / aida Goto Github PK

Possible options:

• Randomized choice of response status from the defined statuses
• Delay on response
• (Check other options from polly and other mock servers)

TODO:

• Add options parameter
• Add delay (timing) option
• Add randomized choice of response status

Try using ShellJS to cleanup the CLI. Aside from general refactoring, try to replace some functionalities with existing libraries if possible.

• timing - Currently it supports a fixed number. Add a [from, to] range to make it randomized within the specified range
• status - Can take the status it wishes endpoints to return. Can take a [from, to] range to randomly return statuses within the range
• routeSettings - Object that can take an exact route (or regex) and take the same options as above and apply them only to that route.
• passthroughRoutes - An array of routes or regex to be passed through

This can be done on a global level, or per-injector level.

Ignoring files and directories is already implemented in the core, so maybe we can use that.

Libraries that can be used internally for validation:

• https://github.com/chriso/validator.js for all string-based validations.
• https://github.com/ianstormtaylor/superstruct
• https://github.com/imbrn/v8n

The validator can accept an array of "types" like unique, id, or custom validation functions.

General flow:

• Get the hash value of each validation function.toString(), and store it in an object such as

const validators = {
[hashval]: () => null,
}

• Iterate over each object in each definition
• Get the validation function
• If it is string, replace it with the hashval for that pre-defined function
• If it is a function get the hash value of that function.toString(), add it to the rest of validators and replace it with the hash value.
• At the end, you can potentially remove the unused pre-defined functions, but it is not necessary for a start.
• Once all validators are generated, output them to a file exported as an object as the validators object above
• In a separate file, create the validation executor which will be the connection between the validator functions and the hash value for each field in each definition.

The injector can be modified whether the SDK should be fully implemented by simply making a request to the endpoint specified, or it should not contain any implementation details and only create a skeleton for it using only the IDs.

The database injector should mimick a specific database API and return fake data.

MongoDB Mocks:

• https://github.com/williamkapke/mongo-mock
• https://jestjs.io/docs/en/mongodb

Currently there is an assumption that injectors are part of @aida/injector-*, which might not be true. Check the CLI getInjectors code for details.