👇🏾 Как выбрать библиотеку не отстрелив себе тестикулы
Вот смотришь на либу в Github и не понимаешь стоит ли ее использовать, или нет
Напишу набор действий, которые делаю я:
– Почитайте код релизов – если библиотека должна развиваться, а релизы были давно или они про изменение доки / 1 строчки кода, то плохо
– Много ли контрибьютор и как часто они коммитят
– Читаем Issues (особенно закрытые) – сколько закрыто, как давно, как много открыто, есть ли среди них критичные для вас моменты. Я находил либы, в которых авторы просто подряд закрывали абсолютно все Issues без ответа и люди недоумевали, что происходит.
– Как много вопросов и ответов на StackOverflow, если много, то хорошо
– Как много статей в интернете по названию библиотеки и какой они даты – Лучше, чтобы библиотека не зависела от кучи других, потому что контрибьютить, придется делать изменения не только в самой либе, но и в завсимостях
– Лучше, чтобы библиотека была в рамках одного стэка – например, в Prisma у вас будет идти еще Rust библиотека трансляции запроса в SQL, а значит чтобы поправить в ней баг, придется править не только JS / TS код, но и Rust
– Есть ли тесты на код – если есть, то это лучше, чем документация
Пример на Objection.js Под постом выше спросили про то, что я думаю, про Objection.js, я пошел освежить память, потому что давно им не пользовался:
– Релиз есть свежий, но он один... до этого релизами не пользовались, поэтому идем в commits и видим что коммиты раз в полгода... для ORM – очень плохо, потому что БД и задачи к БД постоянно развиваются, значит и ORM должна
– Среди контрибьюторов есть создатель Knex – это хорошо
– Идем в Issues и видим, что создатель не может поддерживать эту либу (а энтузиастов так и не нашлось) и сам называет ее устаревшей
На этом уже можно остановится и подвести итог – библиотека мертва
Напишу набор действий, которые делаю я:
– Почитайте код релизов – если библиотека должна развиваться, а релизы были давно или они про изменение доки / 1 строчки кода, то плохо
– Много ли контрибьютор и как часто они коммитят
– Читаем Issues (особенно закрытые) – сколько закрыто, как давно, как много открыто, есть ли среди них критичные для вас моменты. Я находил либы, в которых авторы просто подряд закрывали абсолютно все Issues без ответа и люди недоумевали, что происходит.
– Как много вопросов и ответов на StackOverflow, если много, то хорошо
– Как много статей в интернете по названию библиотеки и какой они даты – Лучше, чтобы библиотека не зависела от кучи других, потому что контрибьютить, придется делать изменения не только в самой либе, но и в завсимостях
– Лучше, чтобы библиотека была в рамках одного стэка – например, в Prisma у вас будет идти еще Rust библиотека трансляции запроса в SQL, а значит чтобы поправить в ней баг, придется править не только JS / TS код, но и Rust
– Есть ли тесты на код – если есть, то это лучше, чем документация
Пример на Objection.js Под постом выше спросили про то, что я думаю, про Objection.js, я пошел освежить память, потому что давно им не пользовался:
– Релиз есть свежий, но он один... до этого релизами не пользовались, поэтому идем в commits и видим что коммиты раз в полгода... для ORM – очень плохо, потому что БД и задачи к БД постоянно развиваются, значит и ORM должна
– Среди контрибьюторов есть создатель Knex – это хорошо
– Идем в Issues и видим, что создатель не может поддерживать эту либу (а энтузиастов так и не нашлось) и сам называет ее устаревшей
На этом уже можно остановится и подвести итог – библиотека мертва
Комментарии: 7
T
I
Докину в следующую итерацию про ORM на тему паттернов блокировок (пост был написан несколько месяцев назад, поэтому нужно проверять актуальность изменений за это время):
В sequelize реализован механизм оптимистичных блокировок через версионность, но об этом нужно знать. В документации, я кстати, что-то не нашёл какой-то инструкции, нашёл только в тестах, что требуется в параметрах модели указать version: true, чтобы в мутирующих запросах использовался этот механизм. Так же они сделали проверку, если незатронуты строки при мутировании данных, то значит, что версия документа не совпала и выдаёт OptimisticLockError.
В prisma - есть проблема, она делегирована на разработчиков, нашёл решение 2 месяца назад через добавление в query builder возможности сделать свою реализацию оптимистичной блокировки.
Лидером выходит пожалуй только TypeORM за лучшую документацию.
Про mongoose. Можно использовать плагин mongoose-update-if-current. Он как раз реализует optimistic concurrency. Но тут придется переопределить обновления с использованием метода .save().
В sequelize реализован механизм оптимистичных блокировок через версионность, но об этом нужно знать. В документации, я кстати, что-то не нашёл какой-то инструкции, нашёл только в тестах, что требуется в параметрах модели указать version: true, чтобы в мутирующих запросах использовался этот механизм. Так же они сделали проверку, если незатронуты строки при мутировании данных, то значит, что версия документа не совпала и выдаёт OptimisticLockError.
В prisma - есть проблема, она делегирована на разработчиков, нашёл решение 2 месяца назад через добавление в query builder возможности сделать свою реализацию оптимистичной блокировки.
Лидером выходит пожалуй только TypeORM за лучшую документацию.
Про mongoose. Можно использовать плагин mongoose-update-if-current. Он как раз реализует optimistic concurrency. Но тут придется переопределить обновления с использованием метода .save().
I
Несколько проектов в продакшене на нём, были лишь небольшие какие-то проблемы, но всё решаемо.
В целом, я бы назвал её одной из самых проработанных ORM, даже среди современных и обновляемых каждый день.
Из минусов контрибьютить в неё действительно больно, например, чтобы расширить диалект обновляемый в knex, в objection необходимо написать абстракций поверх.
В целом, я бы назвал её одной из самых проработанных ORM, даже среди современных и обновляемых каждый день.
Из минусов контрибьютить в неё действительно больно, например, чтобы расширить диалект обновляемый в knex, в objection необходимо написать абстракций поверх.
T
I
🦾
Круто)
Единственное, я бы не назвал "проблемой", то что оптимистические блокировки отданы на реализацию разработчику, в том плане что, сама реализация на уровне одной таблицы несуперсложная, а вот разруливать роллбэк при ошибке лока может стать проблемкой, поэтому я бы и оставлял всегда это на усмотрение разработчика
Ну и как всегда моя претензия к ORM – надо всегда помнить как именно будет реализован тот или иной лок на разных БД (да, только TypeORM док имеет такое описание) и при этом преимущество в виде "смены БД" здесь, мне кажется, не полноценно работает, потому что когда ты начинаешь использовать полноценно оптимистик / пессимистик, то ты точно должен понимать и использовать возможности конкретной БД
Но опятьже, как говорится ИМХО)
Единственное, я бы не назвал "проблемой", то что оптимистические блокировки отданы на реализацию разработчику, в том плане что, сама реализация на уровне одной таблицы несуперсложная, а вот разруливать роллбэк при ошибке лока может стать проблемкой, поэтому я бы и оставлял всегда это на усмотрение разработчика
Ну и как всегда моя претензия к ORM – надо всегда помнить как именно будет реализован тот или иной лок на разных БД (да, только TypeORM док имеет такое описание) и при этом преимущество в виде "смены БД" здесь, мне кажется, не полноценно работает, потому что когда ты начинаешь использовать полноценно оптимистик / пессимистик, то ты точно должен понимать и использовать возможности конкретной БД
Но опятьже, как говорится ИМХО)