Пользователь
0,0
рейтинг
9 марта в 15:12

Разработка → Агрегат для node.js

GitHub и NPM библиотеки.


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

Некоторое время назад я задумался, почему же в node.js работа с реляционными БД, такими как *SQL, и некоторыми noSQL типа Mongo, сложна, и сделал альтернативное решение, заточенное под скорость работы программиста (в сравнении с классическими решениями, заточенных под скорость работы с БД) и прямолинейность и компактность API для минимального порога вхождения. Первым источником вдохновления стал доклад "минимальная поверхность API", вторым — знаменитая цитата Дональда Крута:

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

Дикслеймер 1: описанная тут библиотека находится в стадии ранней беты. Пока что не стоит использовать ее для коммерческих или критичных для вашей жизни проектов.

Дисклеймер 2: в тексте могут встречаться сложные термины, а в примерах кода — множество фич ES6. Если что-то кажется непонятным — пожалуйста, пишите в комментариях, я постараюсь упростить текст и добавить комментарии к коду

Когда я пользовался sequelize — не надейтесь, другие библиотеки не лучше — я невольно задумывался, почему работа с ней так сложна. Не в плане понимания, как она работает изнутри, нет — я зарывался в интерфейс библиотеки. То ли руки не оттуда растут, то ли разработчики - прожженные DBA, не то что я.

Теперь я знаю, что они пытались внести в инструментарий, что могли. На выходе — 15й стандарт, объединяющий предыдущие 14. Показателен в этом плане адский комбайн juggling,  который умеет в крайне разнообразный список БД — MySQL, SQlite3, Postgres, CouchDB, Mongo, Redis, Neo4j.

Но мне для маленьких проектов — всяких телеграм-ботов, дев-серверов и SPA — не нужно было сложной части функционала, что есть под капотом сложных ORM-ок. Базовый требуемый функцоинал - сохранение и поиск записей, выборки по условиям и отношениям. Мне не нужно преждевременных оптимизаций: выборки части полей из базы, хитрых оптимизаций запросов, хранимых функций. Выборку по отношению (получить объект и все связи) можно оформить транзакцией. За счет потери в быстродействии мы получаем отсутствие кучи дополнительных сущностей декларативного синтаксиса. Бритва Оккама в чистом виде.

Лирическое отступление: если посмотреть на историю развития проектов с десятками и сотнями тысяч пользователей - через определенное время разработчики упираются в быстродействие. Они изменяют запросы, БД, языки, платформы, чтобы бы оно работало. Если проект выстреливает — ему предстоит замена деталей, и первой под нож идет работа с базой — если изначально не было потрачено достаточное количество усилий “на будущее”. При этом тяжеловесный, комплексный синтаксис ORM усложняет замену. Вывод напрашивается очевидный — если оценивать выбор ORM как безальтернативный будущий технический долг, корректным выбором может оказаться решение с меньшей эффективностью, но обеспечивающее скорость работы разработчика и предоставляющее минимальный API, что упрощает переход на другое решение.

Я сделал Агрегат


Не БД-, но JS-центричный ActiveRecord —  правда, я местами отошел от классического паттерна.

Важно понимать, что раз он не БД-центричен - БД выбиралась под запросы решения, а не решение делалось под конкретную БД. Хранилищем было выбрано Neo4j. Это решение обладает плюсами и минусами, но пока плюсов больше.

Если вы не знакомы с neo4j — это популярная графовая база данных с гораздо более понятным для непосвященного человека, нежели SQL, языком, удобным веб-клиентом и полнотекстовыми индексами из коробки (используется lucene), и немного меньшим (линейно) быстродействием в сравнении с Postgres/MySQL. Все инструкции по установке есть тут: http://neo4j.com/download-thanks/?edition=community. На mac он ставится через brew install neo4j

Начнем с простого — подключения и записей:

const {Connection, Record} = require('agregate')
const dbPath = 'http://neo4j:password@localhost:7474';
class ConnectedRecord extends Record {
    static connection = new Connection(dbPath);
}
class User extends ConnectedRecord {}
User.register() 
//подготовительная часть завершена, пробуем работать с бд
const user = new User({name: 'foo'})
user.surname = 'bar'
user.save()
.then(() => User.where({name: 'foo'}))
.then(([user]) => console.log(user))  
//=> User {name: 'foo', surname: 'bar'}

Единственное, что выбивается из понятности кода — вызов User.register(). В JS на создание класса нельзя повесить обработчик (и слава разработчикам языка за это), так что приходится делать это за язык.

Метод Record.register делает 3 вещи:

  1. регистрирует данный класс для существующего подключения к БД. Говоря проще — в Map внутри подключения засовывается ассоциация "метка" — "класс". При разрешении ассоциаций (о них позже) именно эта мапа используется для превращения объектов БД в объекты JS

  2. запускает внутренние процессы библиотеки (индексация и ограничение на уникальность uuid в целях безопасности)

  3. запускает индексацию пользовательских индексов (если они были заданы для этого класса).

Для абстрактных классов этот метод вызывать не нужно.

В ES2015 статические свойства наследуются так же, как и свойства сущности - connecton объявляется однажды, в родительском классе, как и было показано. Если у вас одна БД — можно и Record.connection присвоить подключение, хоть это и некорректно с точки зрения разработки.

Отношения и связи


Давайте усложним пример. Представим, что мы делаем ACL, и нам нужны отношения:

const {Connection, Record, Relation} = require('agregate');
// классы Role и Permission выглядят не сильно сложнее
const Role = require('./role');
const Permission = require('./permission');

export default class User extends ConnectedRecord {
    roles = new Relation(this, 'has_role', {target: Role});
    permissions = new Relation(this.roles, 'has_permission', {target: Permission});
    hasPermission = ::this.permissions.has
}

Если не присматриваться — не сразу видишь, что по факту this.permissions - many-to-many through отношение. Синтаксис такого рода дает строить длинные цепочки отношений, для которых доступны полноценные запросы — поиск, удаление, проверка наличия, всё, кроме по понятным соображениям не работающему Relation#add.

Relation подражает встроенному в ES6 объекту Set. API отличается, но он знаком и понятен сразу же. Разница — в том, что методы возвращают Promise, который уже возвращает данные, а size() — метод, а не свойство. Дополнительно появились методы #intersect, который возвращает пересечение передаваемого массива элементов с входящими в отношение элементами, и #where, который делает очевидное, но о нем ниже.

Поиск по БД


Для этого доступны методы с идентичным API: метод класса Record.where() и метод экземпляра класса Relation#where(). Доступны offset, limit, order by, поиск по значению, содержимому массива и вхождению в массив (да, типизированный массив - один из примитивов в neo4j) и подстроке. Возможностей для поиска много. Они покрывают все основные задачи. Перечислять все опции довольно трудно, поэтому проще посмотреть на формальное описание на typescript-подобном синтаксисе:

var dbPrimitiveType = bool | string | number | Array<bool> | Array<string> | Array<number>

async function where(
params?: {
    [string: queryKey]: dbPrimitiveType | {
        $gt?: number //greater than - больше 
        $gte?: number //greater than or equal - больше или равно
        $lt?: number //less than - меньше
        $lte?: number //less than or equal - меньше или равно
        $exists?: bool //существует ли свойство
        $startsWith?: Array<string> | string //начинается с
        $endsWith?: Array<string> | string //заканчивается на
        $contains?: Array<string> | string //содержит подстроку
        $has?: Array<dbPrimitiveType> | dbPrimitiveType //содержит элемент массива
        $in?: Array<dbPrimitiveType> | dbPrimitiveType //входит в массив
    }
}, 
opts?: {
    order?: string | Array<string>; // строка - формата key или key DESC или key ASC, например ['created_at', 'friends DESC']
    offset?: number;
    limit?: number;
},
transaction?: Queryable): Array<Record>

Транзакции


Описанный выше API уже позволяет работать. Остается только вопрос атомарности, который классически решается при помощи транзакций.

В агрегате работать с транзакциями можно двумя способами — простым или понятным.

Понятный способ — использовать транзакции "в лоб". Для этого нужно передать ее последним аргументом (помимо остальных). Все стандартные методы, работающие с БД, поддерживают эту нотацию.

class Post extends Record {
    author = ::new Relation(this, 'created', {direction: -1}).only //тут мы биндим метод only, который является одновременно геттером и сеттером. Он используется для работы с отношениями, где нужна единственная запись.

    async static createAndAssign(text, user) {
        const transaction = this.connection.transaction()
        const post = await new this({text}).save(transaction)
        await post.author(user, transaction)
        await transaction.commit()
        return post
    }
    //или учитывая то, что что-то может пойти не так
    async static createAndAssign(text, user) {
        const transaction = this.connection.transaction()
        try {
            const post = await new this({text}).save(transaction)
            await post.author(user, transaction)
            await transaction.commit()
            return post
        } catch (e) {
            await transaction.rollback()
            throw e
        }
    }
}

Объект connection (который доступен и для класса, так и для экземпляра класса) может быть подключением, транзакцией или суб-транзакцией. Для использования в жизни разницы нет, потому что все три сущности предоставляют один и тот же интерфейс с небольшими внутренними отличиями. Если вызвать connection.transaction(), подключение вернет транзакцию, транзакция — суб-транзакцию, суб-транзакция — другую суб-транзакцию.

Внутреннее отличие заключается в следующем — методы commit и rollback для подключения пробросят ошибку, для транзакции — отработают ожидаемо, для суб-транзакции — commit сделает ничего, а rollback откатит родительскую транзакцию.

Это сделано из-за того, что некоторые методы о генерируют для себя транзакцию и закрывают в конце — например, Record#save(). Чтобы в рамках транзакции корректно работали такие методы — реализована бесконечная вложенность суб-транзакций.

Для второго способа — простого — используется декоратор:

import {Record, acceptsTransaction} from 'agregate'

class Post extends Record {
    @acceptsTransaction
    async static create(text) {
        return await new this({text}).save(this.connection)
    }
}

Он превращает код в примерно такой:

import {Record, acceptsTransaction} from 'agregate'

class Post extends Record {
    async static create(text, transaction) {
        //Queryable - внутренний класс, от него наследуются Connection, Transaction, SubTransaction
        if (transaction instanceof Queryable)
            this.connection = transaction
        try {
            const result = await new this({text}).save(this.connection)
            if (transaction)
                await transaction.commit()
            return result
        } catch (e) {
            if (transaction)
                await transaction.rollback()
            throw e
        }
    }
}

Декоратор можно использовать и прямо, как в примере выше, и конфигурируя. Для конфигурации пока доступен только один флаг — force, который принудительно создает транзакцию — если не передана транзакция, он сам ее создаст. Использовать нужно так: @acceptsTransaction({force: true}) ....

Обратите внимание — теперь this.connection стала транзакцией. Когда отработает функция, свойство вернется в прежнее состояние, но теперь это позволяет вызывать другие методы класса, не заботясь о том, чтобы передавать транзакцию. Работает эта магия только в пределах this (что предсказуемо). 

Поскольку транзакции обрабатываются по очереди, т.е. пока не завершится одна, не начнется другая, клонирования объекта не производится, поэтому учтите: если обернуть статический метод в этот декоратор, можно случайно "пошарить" транзакцию. Для экземпляров класса это не страшно в силу того, что если вы правильно работаете с JS - они находятся в своей области видимости, и из других потоков выполнения (таких как промисы, async-и и так далее) нельзя одновременно получить к ним доступ в силу недоступности объекта.

Вот и весь агрегат


Описание API и причин, почему сделано так, а не иначе, завершено.

Наверное, единственное, что стоит добавить — что я уже использую его в небольших проектах для себя и друзей. Я давно не испытывал такого удовольствия при работе с БД — такое ощущение "прозрачности" и понятности механизмов работы я испытывал только при работе в Ruby/Rails, и даже там приходилось местами мучиться с CLI.

В агрегате может не хватать каких-то возможностей или быстроты, но если вы хотите этого — подключайтесь к проекту. Сейчас агрегат это всего 608 строк (сам в шоке) довольно неплохо организованного кода, и вносить правки, дополнения, обновления, делать дополнительные тесты — очень просто. Я бы хотел видеть его однозначно пригодным к использованию в большом продакшне, и если вам тоже он понравился — подключайтесь к разработке!
Сева Родионов @Jabher
карма
40,2
рейтинг 0,0
Пользователь
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Разработка

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

  • +1
    "… с реляционными БД, такими как *SQL и Mongo..."
    Вероятно, всё-таки с нереляционными. Собственно, в этом и ответ: сложности именно из-за того, что они нереляционные.
    • 0
      Спасибо, поправил — пропустил "осфордскую запятую".

      На самом деле склонен не согласиться. Сложность использования того же mongoose (с кучкой плагинов) примерно равна massive или sequelize. Дело именно в том, что асинхронность (а значит — необходимость делать действительно много синхронизации и невозможность задавать сколько-либо глобальные переменные) ломает многие принципы, которые переносятся из работы с БД в других языках.
  • 0
    Как только я стал писать на koa через функции-геренаторы, то отношение к программированию на nodejs улучшилось в разы. Код пишется так, как-будто все функции работают синхронно. А с учетом того, что на многие пакеты есть promise обертки, которые позволяют работать с кодом также как с синхронным (в koa это сопрограммы кажется называется, но могу ошибаться), программировать на nodejs теперь намного проще.

    Скорее всего есть orm/odm пакеты с промисами.
    • 0
      Да нет, многие ORM/ODM поддерживают promise-ы. Вопрос в другом — они все равно пытаются нести практики из других языков, в которых эти практики работают в рамках потока. К тому же эти библиотеки пытаются скрыть очень много логики внутри большого количества фабрик, генерирующих свои внутренние объекты и выставляющие наружу сложный API.

      Так, например, в каком-нибудь ruby при попытке получить массив по отношению (например author.posts) — синхронно отработается внутренний запрос к БД. Решения в JS же пытаются придумать синтаксис для предварительной подгрузки этих данных (т.к. надо делать асинхронный запрос, синхронные-то недоступны), или пытаются это решить каким-то другим образом, тоже не очень очевидным. Вместо того, чтобы использовать преимущества JS — они пытаются сгладить его недостатки огромным API.
      • 0
        Так с промисами работа получается с точки зрения кода почти синхронной:

        var posts = yield odm.findAllAsync(); // findAllAsync return Promise
        var posts2 = odm.findAllSync();

        Вот что я имел ввиду, мы работаем не с колбеками, или ветками .then(), а из асинхронной функции получаем результат, как бы синхронно с точки зрения скрипта.
        • 0
          Зачем вы используете odm? Вам действительно удобней?
          • 0
            Eternalko, Тут вопрос не в odm или драйвере, а как их использовать, с "callback адом" или с yield как "синхронный flow".

            Львиная доля сложности может уйти и при работе с odm, если изменить flow с асинхронного на синхронный.
            • 0
              и львиная доля перфоманса Node.js заодно
              • 0
                Использую koajs где все так построено, проблем с performance не испытываю. Можете информацией поделится, откуда вы это взяли?
                • 0
                  Так, вы меня запутали. Вы используете синхронный флоу или корутины/файберы для того, чтобы убрать колбэки? Есть разница. Указанный в примере выше odm.findAllSync займет весь поток выполнения JS и не даст обрабатываться другим запросам.

                  В JS в условиях файберов/асинхронного выполнения нужно понимать, как все работает, чтобы не словить deadlock или мутирование внутреннего состояния, это не синхронный флоу.
                  • 0
                    odm.findAllSync — не используется, это для примера чисто. Что асинхронный вызов с yield с точки зрения кода можно сопоставить с синхронным вызовом. Под "синхронным flow" я имею ввиду не вызов синхронных функций, а стиль работы с кодом, как с синхронным.
            • 0
              AlexPTS я про odm и драйвер спрашивал)

              Просто нативные драйвера настолько хороши в node что использовать odm не вижу смысла.

              В разговор об асинхронных паттернах вдаваться не буду. Тема избитая(:
  • 0
    А я использовал mysql и mongoose как в мелких, так и в крупных проектах. И бед не знал. И мне всегда было глубоко пофигу неважно что на кросс-sql-ность (sqlite, mysql, pgsql, ...), что на кросс-nosql-ность (mongo, couchdb, redis, ...). В некоторых проектах даже использовал для разных данных оба модуля mysql и mongoose одновременно.
    Собственно, простота реализации, модернизации и оптимизации!
    • 0
      Советую нативный драйвер вместо mongoose. На сегодняшний день api нативного просто удобней
  • 0
    Так я и не понял до конца. Судя по всему — вам же обычный query builder нужен. knex пробовали? Если да — чем не устраивает?

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.