17.01.2019 18:16
SergeyEgorov 0 817 Источник

Сегодня состоялись разномасштабные испытания команды запроса данных из базы, процесс разработки которой подробно и очень многословно был описан здесь и здесь.


Что показали испытания? Команда работает, но… в том сценарии использования, в котором ее приходится задействовать, ее неудобно настраивать.


Как я упоминал в первой публикации, максимально для каждого обмена данными с поставщиком KYC услуг, из базы надо выбирать относительно много записей. Более десятка. Поведение алгоритма извлечения записи из базы в рамках каждого запроса идентичное, изменяются только настройки. Если бы я сначала написал интеграционный тест, который демонстрирует именно боевой сценарий использования, мне было бы понятно какие ключевые детали нельзя упускать из виду. Интеграционный тест мог бы выглядеть например вот так:


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');
  }
});

Кардинальность отличия в том, что мы заранее готовим правила конфигурации запросов и храним их в словаре context.rules. А этот словарь и другие необходимые для выполнения запросов и сохранения результатов объекты, содержатся в контексте, который мы собираем из предварительно сконфигурированного хранилища базы данных context.db, предварительно сконфигурированного хранилища контейнера состояния context.store, и вышеупомянутого словаря.


При этом правила конфигурации запросов могут содержать как обычные строковые данные, например имя таблицы, из которой надо запросить данные, так и фабричные методы, формирующие запросы к базе и методы диспетчеризации, отправляющие действия контейнеру состояния. При таком раскладе настройка нужных команд выглядит совершенно иначе, нежели предполагает уже существующий код.


Такое архитектурное решение позволяет нам в том числе определять различные уровни KYC проверок, просто в виде наборов строк (Set), которые используются как ключи при хранении правил конфигурации запросов. К примеру если мы хотим отправить на проверку только персональные данные и адрес, мы просто в набор строк помещаем соответствующие ключи: user, person и address.


В вышеозначенном тесте показан максимальный вариант конфигурации, с обходом всего словаря правил и настройкой обобщенного код запроса, на конкретные таблицы. Ну и как видно в коде ниже, собственно запуск запросов будет происходить как реакция на события изменения контейнера состояния:


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

context.store.subscribe(handle);

Описания процесса реализации во всех леденящих кровь подробностях сегодня не будет, ибо оная еще не состоялась...

Комментарии (0)