Лучший способ заявить о себе как о специалисте в какой-либо области — показать другим людям в этой области, что вы знаете, как делать разные вещи — например, полностью перестроить серверную часть всего проекта, чтобы использовать SQL через knex вместо MongoDB через mongoose. Позвольте мне прояснить, это не была бы статья, если бы все прошло гладко. На самом деле это был второй проект, который погряз в той же трясине неуверенности в том, чтобы снова заставить этот материал работать после того, как он был переписан. Решение проблем позволило мне, наконец, вытолкнуть их оба на свой сервер через докер в рабочем состоянии.
Добро
Предоставление кредита там, где это необходимо, фактически обращение к базе данных для получения результатов, так же просто с использованием любой технологии. После того, как вы пройдете все дополнительные шаги — запуская одну команду knex за другой, чтобы она создавала для вас файлы, которые вы в конечном итоге просто удалите, — вы в конечном итоге запросите либо пользователя, либо тако с id и отправить его обратно в качестве ответа. Количество строк между двумя методами создания, чтения, обновления или удаления записи на самом деле является преимуществом для knex.
Одним из таких примеров является функция tacoController.getComplete(), которая увеличилась с 54 строк до 37 строк при переходе на SQL и, честно говоря, может быть очищена даже лучше, чем это, с небольшим рефакторингом.
Я, конечно, хотел бы пожаловаться на то, насколько больше документации было необходимо прочитать, чтобы использовать knex, даже на базовом уровне, по сравнению с мангустом, но это связано с территорией. Так где же зависание!? Подумаешь!? Большое дело было…
Плохое
Развертывание! Одно быстрое нажатие на волшебство Google отображает множество статей, которые помогут, и множество людей, помеченных как ДУБЛИРУЮЩИЕ ПОСТЫ (удушье!) в stackoverflow с просьбой о помощи — все они связаны с выполнением этих надоедливых команд knex для миграции и семян как часть их настройка докера.
Соглашение, которое я выбрал для использования в своих проектах, помещает папку knex в корневой каталог, поэтому в package.json я добавил две записи в раздел сценариев, чтобы изменить каталог с последующей миграцией и заполнением. Хитрость заключалась в том, чтобы запустить мой контейнер три раза на сервере, каждый раз с другой командой: yarn migrate, yarn seed, yarn start.
&& Уродливый
Прошли годы с тех пор, как я по какой-либо причине администрировал свою собственную базу данных SQL, поэтому, хотя я сразу понял, что ошибка, с которой я столкнулся, была связана с тем, что никто не запускал «CREATE DATABASE tacotaco;» Я все еще был глубоко раздражен. Ничего из этого не происходит с MongoDB. Может показаться, что этот раздел не работает после развертывания, но все это работало в настройке разработки. Проект работал в SQLite, но переход на MySQL создал новые шаги h̶i̶c̶c̶u̶p̶s, включая изменения в коде.
НАКОНЕЦ миграция была выполнена, и заполнение завершилось с ошибкой. Счастливого конца пока нет! На отладку и удаление базы данных ушло еще немного времени, прежде чем я смог определить, что записи HTML слишком велики для использования строки MySQL в качестве типа данных. Потребовалось несколько итераций одной строки в миграциях (и короткий скрипт, чтобы получить длину самой большой записи, которую я удвоил), прежде чем я, наконец, смог заполнить базу данных всеми тако!
Мысли?
Все сказано и сделано, возможность свободно выбирать, какую из этих комбинаций технологий я предпочитаю использовать при создании личного проекта, это, безусловно, будет MongoDB, но полезно знать, как обойти все варианты.
