Developing a team to request data from the database - part 3

Today, multi-scale tests of the data request team from the database took place, the development process of which was described here and here in detail and very verbally .

What did the tests show? The team works, but ... in the usage scenario in which it has to be activated, it is inconvenient to configure.

As I mentioned in the first publication, as much as possible for each data exchange with a KYC service provider, relatively many entries should be selected from the database. More than a dozen. The behavior of the algorithm for extracting a record from the database is identical within each request; only the settings change. If I had first written an integration test that demonstrates the combat usage scenario, I would understand which key details should not be overlooked. An integration test might look like this:

describe('configure and run database requests', () => { const context = require('../src/storage/requestContext'); const requestHandler = require('../src/storage/requestHandler'); it('should get full recordset from db', (done) => { for(let key of context.rules.keys()) { let handle = requestHandler.bind(context, [key]); context.store.subscribe(handle); } const assert = checkDataIsReady.bind(context, [done]); context.store.subscribe(assert); const note = { Id: 1, UserId: 38 }; const start = { type: 'NOTE', note }; context.store.dispatch(start); }); function checkDataIsReady(args) { if(notAllDataIsHereYet()) return; checkUserRecord(); // // Здесь добавляем нужный код, проверяющий // что все записи из базы данных загружены // const checkIsCompleted = args[0]; checkIsCompleted(); } function notAllDataIsHereYet(){ // // Здесь код, который проверяет // все ли данные получены из базы // return false; } function checkUserRecord(){ const user = context.store.getState().user; expect(user.Id).toEqual(38); expect(user.Name).toEqual('Jack'); } }); 

The cardinality of the difference is that we prepare in advance the rules for configuring requests and store them in the context.rules dictionary. And this dictionary and other objects necessary for executing queries and storing the results are contained in a context that we collect from the preconfigured database store context.db , the preconfigured repository of the context.store state container, and the above dictionary.

At the same time, query configuration rules can contain both ordinary string data, for example, the name of the table from which data should be requested, as well as factory methods that form queries to the database and dispatch methods that send actions to the state container. In this scenario, setting the necessary commands looks completely different than it already implies the existing code.

This architectural solution allows us, among other things, to define various levels of KYC checks, simply in the form of rowsets ( Set ), which are used as keys when storing query configuration rules. For example, if we want to send for verification only personal data and an address, we simply place the corresponding keys in the rowset: user , person and address .

In the above test, the maximum configuration option is shown, with a crawl of the entire rules dictionary and setting up a generalized request code, to specific tables. Well, as can be seen in the code below, the actual launch of requests will occur as a reaction to the events of a change in the state container:

 let handle = requestHandler.bind(context, [key]); context.store.subscribe(handle); 

Descriptions of the implementation process in all chilling details of the blood today will not, because it has not yet taken place ...