Рубрика:

Опубликовано:

14.04.2021

Как мы делали WorkApp и чинили чужие библиотеки

Заметки
14.04.2021

Ведущий разработчик рассказывает:

Для разработки серверной части WorkApp мы выбрали TypeScript. Среди всего разнообразия возможных ORM в мире NodeJS нами была выбрана typeorm, как библиотека, с которой мы уже имели опыт работы. Библиотека, в большинстве своём, ужасная и являющая из себя каноническим примером «индуского» поделия (правда, в этот раз отличился таджик). Но она имела два преимущества: была типизирована, и имела нативную интеграцию в NestJS фреймворк, который нам так полюбился.

Система уже на половину написана, а проблемы в работе с БД всё копятся и копятся. В определённый момент уже достало решать проблемы из-за typeorm и начались поиски альтернатив. Возможность внесения исправлений самостоятельно в typeorm было моментально отвергнуто ввиду очень плачевного состояния его исходников.

В процессе поисков альтернативы всплыла другая библиотека. Она была написана довольно качественно, имела полную типизацию и поддерживала «Unit of work». Одна беда – эта библиотека работала на тот момент только с mongodb. Каково же было наше удивление, когда вышла новая версия с поддержкой реляционных БД. Название данной библиотеки – «mikro-orm», и на тот момент поиск подходящей ORM был завершен.

Единственным реальным недостатком mikro-orm было на тот момент одно — переход от nosql БД к поддержке большого количества разнообразных БД, и из-за этого стабильность некоторых функций ещё плавала.
Прекрасно осознавая, что в процессе перехода на новую ORM мы столкнёмся с техническими проблемами, мы начали реализацию нового инфраструктурного слоя приложения, благо интерфейсы уже были спроектированы и надо было их просто соблюсти.

По итогу, единственная проблема, с которой мы столкнулись при переезде была следующей — для хранения информации об изменениях в задачах пользователей, мы использовали дизайн таблицы, эмулирующий timeserises-хранилище. Для такой реализации необходимо использовать композитный первичный ключ, состоящий из строки и даты. Это позволяло нам очень эффективно хранить все ревизии записей в одной таблице и иметь к ним простой доступ. Typeorm с таким справлялась достаточно просто (нет валидаций — нет проблем), а вот у mikro-orm начались проблемы. Создание задач в WorkApp поломалось, а тесты данного функционала покраснели. Понимая, что проблема явно не на нашей стороне — было решено обратиться к разработчику напрямую в slack-чате. На удивление, ответы мы получили быстро, но пришлось потратить какое-то время на споры и доказательства того, что такой дизайн имеет право быть и он предусмотрен БД. Также выяснилось, что проектом занимается один-единственный человек, а это означало что добраться до решения нашей проблемы он сможет лишь только через неделю, в порядке живой очереди. Нас это не устраивало, потому мы решили внести изменения самостоятельно: https://github.com/mikro-orm/mikro-orm/pull/587

Нам очень полюбилась данная библиотека и далее мы стали её использовать в других проектах. По ходу мы выявили и исправили ещё одну проблему: https://github.com/mikro-orm/mikro-orm/pull/998

Также сообщили ещё о четырёх менее критичных (для нас) ошибках:

Сейчас, в 2021 году мы занимаемся разработкой ERP-системы для промышленного предприятия. Опять TypeScript, опять Mikro-ORM и автор библиотеки уже пишет на упреждение «ТОЛЬКО НЕ ТЫ», когда наш ведущий разработчик заходит в чат.

Поделиться
Share on vk
Share on twitter
Share on facebook
Share on telegram
Share on whatsapp

Обсудите ваш проект с менеджером

    Я согласен на обработку персональных данных согласно политике конфиденциальности

    Служба поддержки