Knex против mysql2, основанные на производительности, стабильности и поддержке ES8 +

Question

Кто-нибудь имеет практический опыт работы с обеими DB-библиотеками - knex против mysql2?

После некоторого поиска в Google (например, при NPMCompare ), мне все еще любопытно узнать, исходя из реального опыта, каковы плюсы и минусы обоих вариантов?

Пока единственное реальное преимущество использования Ясно вижу, knex over mysql2 - это универсальная поддержка MS SQL, MySQL, PostgreSQL, SQLite3 и Oracle, в то время как последний поддерживает только MySQL, но, поскольку в настоящее время я фокусируюсь только на MySQL, эта функция knex представляется менее актуальной.

Параметры, которые я хотел бы рассмотреть:

• Производительность и устойчивость к нагрузкам;
• Стабильность (готовность к производству);
• Встроенная поддержка ES8 + (без обратного вызова, без лишних Util.promisify обертки, ESM / M JS поддержка);
• Коротко и ясно, чем меньше многословно, тем лучше.

Answer 1

Я использую knex в своем основном проекте, я думаю, что вы пытаетесь сравнить яблоки с апельсинами, потому что Knex - это построитель запросов, который подчеркивает, использует (mysql2) в качестве транспортного lib (в случае использования MySql) ).

Преимущества, которые я вижу в Knex:

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

Так как # 3 является таким большим преимуществом, на мой взгляд, лучше продемонстрировать это:

Думаю, у вас есть 2 конечные точки

1. /users/list - что Предположим, чтобы вернуть список пользователей ({id, name})
2. /users/:id - которые предполагают, чтобы вернуть одного пользователя с такой же структурой.

You можно реализовать так:

async function getAllUsers() {
  return db('users').columns('id', 'name'); //think that this can consist of many joins
}

async function getUserById(userId) {
  return getAllUsers().where('id', userId);
}

Посмотрите, как getUserById повторно использует тот же запрос (может быть очень сложным), и просто «добавив» необходимое ограничение.

С точки зрения производительности, я не думаю, что эта абстракция имеет большую стоимость (я еще не замечал проблем с производительностью)

I Я не уверен, что вы называете стабильностью, но у Knex есть действительно классная поддержка TS, которая может сделать ваши запросы строго типизированными.

interface User {
  id: number;
  name: string;
}

const users = await db<User>('users').columns('id', 'name'); // it will autocomplete the columns names & users will be of type User[] automatically.

С комбинацией автоматической генерации этих типов БД из БД с использованием @ typed-code / schemats это значительно облегчает работу и рефакторинг.

Начиная с ES6, Knex по умолчанию поддерживает обещания и обратные вызовы, поэтому вы можете выбирать все, что вам подходит.

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

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

Mysql2 является драйвером низкого уровня над БД.