Как эффективно использовать 'сервисы' для обращения к БД?

Question

[Gahoy]

У меня сейчас, слишком много сервисов получаются (под сервисами я имею в виду файлы в которых функции обращаются к БД).

К примеру,

Для того чтобы проверить существет аккаунт с таким email приходиться делать одну функцию

export const findUserByEmail = async (
  email: string
): Promise<boolean> => {
  try {
    const users = await db
      .query('SELECT email FROM accounts WHERE email = $1', [email])

    return users.rows.length !== 0
  } catch (error) {
    console.error(error)
    throw error
  }
}

И их очень много

createUser
findUserByEmail
getUserByEmail
createUserToken
deletePreviousUserTokens
getRefreshToken

Их можно как то оптимизировать:
1. Нормально ли создавать столько функции, каждый под свои нужды ? (Что-то мне кажется что я не так их использую, а по другому как понятия не имею)
2. В каждом из функции все повторяется кроме самого запроса, (и везде try-catch еще), можно как то это оптимизировать ?
3. Подскажите, как вы делайте что-то подобное, чтобы пример увидеть, желательно разные подходы.

Answer 1

[mayton2019]

По поводу смыслов. Обычно с БД работают сущностями (entities). Я не специалист в Node и я не знаю
как у вас принято. Кажется в новых ecma-спецификациях уже ввели понятие класса.

В данном коде идет проверка на то что email существует. Но полезный эффект - слабый.
Я-бы сразу возвращал сущность пользователя. Чтоб не бегать потом в базу еще
раз когда надо поискать имя или дату регистрации. Ну идея такая что
если вы уж пошли в базу (это сетевой round-trip) то постарайтесь
за этот трип собрать максимум информации.

Вот это более рационально

export const findUserEntityByEmail = async (
  email: string
): Promise<User> => {
  try {
    const users = await db
      .query('SELECT * FROM accounts WHERE email = $1', [email])

Тоже самое относится к выборкам множества строк по множеству ключей.
Лучше сделать 1 callback который вернет коллекцию чем для коллекции
ключей дергать один несчастный метод который по штучке что-то достает.

Еще важне - join. Если соединяете сущности - то соединяйте сразу в БД
без попыток соединять в приложении. Это кстати еще бонус к компетенции
в части ACID.

Тоесть идеальный вариант работы с БД - запросить пакетом всю информацию
что может потербоваться на ближайшие несколько секунд. Это рациональнее
чем потом что-то подтягивать.

Comments

[Gahoy]

Я понимал, что 'сервисы' нужны для каждого функционала отдельно, и минимально запрашивать данные.

[Gahoy]

так будет лучше ?

class UserServices {
static function deleteUser () {} // 
static function createUser () {} // 
static function updateUser () {} // 
static function getUserById () {} // тут получаем все данные о пользователе по id
static function getUserByEmail () {} // тут все данные о пользователе по почте
static function getAllUsers () {} // все данные про всех пользователей
}

И в принципе больше ничего и не нужно, получается что это основные.

[mayton2019]

Твой вопрос начинался

Как эффективно использовать 'сервисы'

Возможно я старый и глупый. И я под эффективностью понимаю эффективность использования БД. Тоесть - перформанс и отсуствие лишних действий.

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

Я-бы createUser, updateUser просто заменил на один метод

static function upsertUser () {} //  если нет - то создает. Или если есть то обновляет

Вот. С моей точки зрения не стоит плодить методы которые делают очень похожие вещи.
Все равно тебе нужно проверять статус ошибки при createUser если таковой уже существует.

[Gahoy]

mayton2019, команды разные же, к примеру для обновления update а для создания insert into. Возможно я не так понял.

[mayton2019]

Gahoy, в некоторых случаях смогу доказать что одна DML команда нужна.

Что у тебя за БД. MySQL? PG?

[Gahoy]

mayton2019, PG

Answer 2

[Дмитрий Макаров]

Как раз нормально так делать! Если их слишком много станет они сами сложатся как паззл.
Можно загнать в объект но это просто сахар. Функциональный стиль тоже хорошо.