FOR: архитектура поиска данных как самостоятельный слой системы

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

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

И в какой-то момент становится заметно: поиск реализуется не как единая система, а как набор разрозненных решений.

Именно в этот момент возникает потребность не в очередной оптимизации, а в переосмыслении — вынести поиск в отдельный уровень абстракции.

Так появилась концепция, которую я называю FOR (Filter / Options / Response).

Ключевая идея FOR заключается в очень простой мысли: поиск данных должен описываться, а не программироваться

Это означает, что вместо написания кода под каждый сценарий мы вводим универсальный способ описания запроса, который может быть:

Таким образом, поиск становится не функцией backend-а, а контрактом, понятным всей системе.

FOR разбивает любой запрос на три независимые части:

• Filter — что искать

• Options — как расширить данные

• Response — как обработать результат

Это разделение может показаться очевидным, но именно оно позволяет избежать накопления сложности.

В основе Filter лежит максимально простой примитив:

объект — оператор — значение

Это не попытка упростить реальность, а сознательное ограничение. Любой фильтр, каким бы сложным он ни казался, можно разложить на такие атомы.

Важно, что объект здесь — это не просто поле в таблице, а элемент некоторой системы типов. Это позволяет работать не с конкретной базой данных, а с абстрактной моделью.

Фильтры могут объединяться, но не через усложнение синтаксиса, а через композицию:

Такой подход даёт предсказуемость: мы не создаём язык, который нужно изучать, мы собираем выражения из простых блоков.

Одна из распространённых проблем — попытка “всё уместить в фильтр”. JOIN’ы, связанные данные, дополнительные вычисления — всё это начинает проникать в условия поиска и делает их громоздкими.

В FOR это решается иначе.

Filter отвечает только на вопрос “что выбрать”,

Options — на вопрос “что к этому добавить”.

Options позволяют “насытить” результат:

При этом сам фильтр остаётся чистым и понятным.

Третья часть — Response — отвечает за то, что происходит после получения данных.

Здесь могут быть:

Это позволяет не смешивать:

И снова — за счёт разделения снижается сложность.

FOR сам по себе — это описание. Чтобы он начал работать, нужен интерпретатор.

Эту роль выполняет Provider.

Provider:

Важно, что Provider работает поверх абстракций:

Это означает, что сама система не зависит от способа хранения данных.

Если в какой-то момент:

Достаточно изменить Provider, не затрагивая остальную систему.

FOR особенно хорошо раскрывается там, где есть строгая система типов.

Контракт в данном случае — это описание:

Он может быть реализован по-разному, но ключевая идея в том, что: система знает, с какими данными она работает

Динамические поля при этом не запрещены, но меняют характер системы. Частые изменения структуры приводят к необходимости пересмотра правил, и в таких сценариях FOR теряет часть своих преимуществ.

Одно из наиболее ощутимых последствий использования FOR — это изменение скорости разработки.

Недавно я столкнулся с задачей: нужно было быстро реализовать backend для нового сервиса.

В классическом подходе это означало бы:

• проектирование API

• реализацию фильтров

• написание логики выборки под каждый сценарий

Вместо этого я:

После этого поиск по всем сущностям стал доступен практически сразу.

Мне не пришлось:

Система начала работать благодаря своей абстрактности.

Дальше:

И всё это — без переписывания поисковой логики.

Ещё одно важное следствие — возможность переиспользования.

Если в системе есть приложения вроде:

Они могут работать с одним и тем же источником данных.

Меняется только FOR-запрос.

Это даёт возможность:

Фактически, пользователь начинает работать не с кодом, а с моделью данных.

Лучшие результаты достигаются в системах:

Особенно хорошо он работает там, где:

FOR не претендует на универсальность.

Он не предназначен для:

Также он может быть избыточен:

Важно понимать его роль: это не замена архитектуры, а её специализированный слой

Теперь имеет смысл перейти от концепции к практике и ввести более предметный контекст.

Представим задачу: необходимо быстро разработать небольшое программное обеспечение, в котором есть 10–20 типов данных (это условность — подход масштабируется практически без ограничений) и десятки различных представлений этих данных.

Сами данные связаны между собой:

В качестве примера возьмём систему управления тестовой документацией.

Для MVP определим следующий набор типов:

Даже на этом уровне уже становится очевидно: количество связей и сценариев выборки будет быстро расти.

Внутри системы вводится базовое описание FOR:

export class typeFOR extends familyService
{
filters;
options;
response;
}
export class typeFilter extends familyService
{
object = {
attribute: false,
};
operator;
value;
}

Здесь важно не столько само объявление, сколько идея:

Response

Обычно сюда удобно выносить:

Options

Options отвечают за “насыщение” данных.

Например, если мы работаем с массивом typeTestCase, то поле typeTestCase.test_suite_id (которое является числовым идентификатором) может быть заменено на полноценный объект typeTestSuite.

Таким образом, вместо join-логики на уровне фильтра мы явно управляем обогащением результата.

Далее весь API-слой оборачивается в единый сервис, например ApiService.

Каждый тип данных получает унифицированный набор операций:

ApiService.[element_type].[search / create / update / delete]

В контексте поиска нас интересует:

ApiService.typeTestCase.search(payload)

С точки зрения frontend это даёт предельно простую и единообразную модель взаимодействия.

Независимо от того, где именно в приложении выполняется запрос, код выглядит одинаково:

let filters = [
new typeFilter({
project_id: project_id
}),
];
let payload = new typeFOR({
filters: filters,
...
});

Далее запрос передаётся в API, и в ответ приходит:

На этом уровне взаимодействие становится максимально предсказуемым.

Любой frontend-разработчик, в любой части приложения, работает с backend через одну и ту же абстракцию: Api + FOR.

Теперь перейдём к backend-части — именно здесь раскрывается ключевая ценность подхода.

Основной элемент — это слой DataProvider.

Он получает:

И выполняет поиск по переданным атрибутам.

При этом:

Рядом с DataProvider (или внутри моделей) размещается всё остальное:

Сам DataProvider при этом остаётся максимально простым: он умеет только интерпретировать FOR и извлекать данные из модели

За счёт такой структуры достигается важный эффект.

Добавление нового типа данных включает:

После этого:

• поиск уже работает

• API уже готов

• дополнительная логика минимальна

Это возможно потому, что весь механизм поиска уже реализован на уровне абстракции.

Несмотря на то, что FOR изначально ориентирован на поиск, он удобно применяется и в бизнес-логике.

По мере развития системы:

При этом структура остаётся прежней, а сложность растёт управляемо.

В результате получается система, в которой:

И, что особенно важно: система становится доступной не только разработчикам

При наличии соответствующих интерфейсов и ограничений:

могут:

без необходимости писать код.

Разумеется, это возможно только при условии, что и остальные части системы сведены к таким же простым и абстрактным конструкциям.

FOR — это попытка упростить не код, а мышление о данных.

Он вводит:

• единый способ описания поиска

• чёткое разделение ответственности

• независимость от инфраструктуры

И за счёт этого даёт:

• ускорение разработки

• снижение сложности

• возможность расширения без переписывания системы

Это не инструмент в привычном смысле, а скорее набор принципов, который можно реализовать по-разному.

Но как только поиск в системе перестаёт быть тривиальным — появляется смысл задуматься о том, чтобы описывать его как отдельный язык.