💾 Data Access Layer ​

Слой взаимодействия с внешними данными мы в дальнейшем будем называть DAL (Data Access Layer).

Данный термин позаимствован из мира серверной разработки (если еще точнее — из .NET). Однако весьма удачно описывает роль этого слоя приложения.

Источники данных — вещь изменчивая.

Всем знакома ситуация, когда даже на небольших промежутках времени в живом проекте меняется формат эндпоинтов HTTP-API, добавляются новые источники данных (например, в дополнение к HTTP-API появляется socket.io соединение или стороннее HTTP-API) и так далее.

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

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

Поэтому все знания об источниках данных и их интерфейсах инкапсулирует DAL.

Для внешнего приложения он предоставляет прозрачное API для получения и мутации данных (коллекция эффектов и эвентов).

Самое важное здесь то, что внешнее приложение не должно ничего не знать о том, откуда эти данные приходят. Именно поэтому соответствующий каталог в демонстрационном приложении назван именно "dal", а не "rest-api" или "http".

DAL может хранить внутри себя состояние, которое непосредственно относится к внешнему источнику данных, например, JWT access token.

Рассмотрим реализацию слоя DAL и его взаимодействие с остальным приложением на нашем демо-примере.

В каталоге dal/request находится модель:

1. Стор $accessToken.
2. События для инициализации и перезагрузки состояния аутентификации initAuthState, resetAuthState.
3. События для аутентификации и изменения токена authenticate и tokenChanged (на случай если нам понадобится поддерживать механизм рефреша токена).
4. Эффекты-обертки над http-запросами requestFx и authRequestFx.

Вся основная логика расположена в init.ts Здесь связывается стор $accessToken с эвентами аутентификации, предоставляется имплементация для requestFx и authRequestFx, а также обеспечивается сохранение и чтение токена из localStorage.

Эффекты с внешним API, оборачивающие http-эндпоинты, находятся в корне точки входа в файлах auth.ts и products.ts.

Для маппинга параметров запроса и ответа мы используем attachWrapper из библиотеки @42px/effector-extra.

Тут стоит обратить внимание на forward в auth.ts:

forward({
  from: signInReqFx.doneData.map(({ token }) => token),
  to: authenticate,
})

Этот forward автоматически установит $accessToken при успешном резолве эффекта signInFx. Внешнему приложению не нужно об этом беспокоиться.

Upd 12.11.23 В актуальной версии effector (v22) рекомендуется использовать sample вместо forward.
https://effector.dev/docs/api/effector/sample

Все что остается внешнему приложению:

1. Инициализировать состояние аутентификации в тот момент, когда инициализируется само приложение. Это происходит в features/app/model/init.ts.
2. Импортировать эффекты для получения/мутации данных и присоединить к ним пользовательский ввод. Пример можно посмотреть в модели sign-in.

Данная схема является лишь одной из возможных. Конкретная реализация внутренностей слоя DAL и его API зависит от задач конкретного приложения, его источников данных и способов аутентификации и авторизации.

Помимо методов для получения и мутации данных, слой DAL также может предоставлять внешнему приложению типы основных сущностей (в демо-примере это src/dal/entities.ts) и моки данных для тестирования.

Подытожим:

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