Понял. спс

И часто приходится менять базу данных на уже работающих проектах?

это запрещенный приём, такими вопросами вы рушите уютненький мир оверинжиниринга :)

😁

мне нет. Хотя не саму базу, а к примеру ОРМ или её логику, да частенько. Это нормальные рабочие процессы. Проще иметь возможность, что-то сделать быстро и качественно. Чем не иметь таких возможностей, без того что бы сесть на бутылку. В моем случае такое было один раз, была postgress на проекте, но несколько модулей зеказчик решил вынести в облако aws с их базами, а еще один из-за раздувшейся базы перевести на кассандру. Думаю не нужно объяснять, какая это боль, если у вас в таком случае увязаны бизнес логика и модели базы данных?

Всем привет. Только недавно начал работать с нодой и непойму, почему удаляется npm. Может ли его тереть антивирус?

Распишу более подробно, у меня есть метод в отдельном файле:
 async getAllFiles(req, res) {
   const file = await File.find();
   res.send(file);
 }
Нужно написать тест(jest), который проверит работу метода, мокнув зависимости,
а именно File, который импортируется из другого файла и его метод, ну
res, req, res.send. И он должен например сравнить возвращаемое значение с
предопределенным, есть кто понимает как эту логику выстроить?

а можете пример скинуть? А-то что-то у меня не получается. Сервер - apache. Хотя, если я через postman отправляю запрос на регистрацию пользователей (с указанием порта) - то ответ приходит нормальный.

для моков импорта можно юзать что-то типо https://www.npmjs.com/package/rewire или применять DI. Вот только не понятно что вы собираетесь тестировать

Тестировать собираюсь приложение для загрузки, редактирования удаления файлов, где инфа о файлах сохраняется в бд, и соответственно тот метод ищет всю инфу о файлах в бд и просто ее выводит

А использовать нужно онли джест

пример чего, вашего кода? Я его не видел. Пример как настроить проксирование? Так в гугле это находится за 2 минуты. Но если что то вот: https://httpd.apache.org/docs/2.4/howto/reverse_proxy.html https://stackoverflow.com/questions/8541182/apache-redirect-to-another-port

тогда ДИ применить типо такого:

function createRouter(File){
  return (req, res) => {
     const file = await File.find();
      res.send(file);
 }
}

и передаете туда мок. Только мне не понятно зачем базу тестить

function createRouter(File){
  return (req, res) => {
     const file = await File.find();
      res.send(file);
 }
}

та не базу, а файл контроллер, где вся логика прописана взаимодействия с базой и файлами

Мне почему-то кажется, что и в вашем случае перенос нескольких модулей не был дешёвой операцией
Так если нет разницы, зачем платить больше?
Достаточно распространена практика реализации бизнес-логики в самой базе, вьюхи, хранимки и прочие прелести. Иногда и такой подход норм
Да и использование орм не та практика, которую можно однозначно рекомендовать. Особенно если у вас бывали замены орм (это вообще зачем, кстати?)

в том примере, что вы предложили нечего тестить. Если хотите тестить контроллер - вам нужны АПИ тесты(наверное). Можете попробовать supertest, если у вас express https://www.npmjs.com/package/supertest

как в экспрессе отменить запрос?
Например, мы шлем большой запрос размером 1мб, он шлется ведь все равно потоком.
Как мне раньше времени отменить запрос до его полного аплоада?
Скажем, прервать аплоад стрим и швырнуть например 403 ошибку?

ОРМ менялись потому что, одна орм переставала отвечать требованиям проекта. Выбор использования ОРМ, часто не мой. Я вообще предпочитаю использовать ОРМ только для NoSQL, так как проверки типов и валидация модели, в SQL, обходится нативом, благо он предлогает богатый инструментарий.
Насчет дороговизны переезда, не поверите, это сильно дешевле, когда модуль базы, выкорчеван из бизнес логики. В этом случае вы точно знаете что нужно переписать, и реализовать это легче, чем переписывать половину приложения. Правда писать такие приложения сразу, сильно сложнее.
Так я и не спорю, что и аткой подход имеет право на жизнь, просто это не гуд. Тут нужно отдовать себе отчет, что если вы пишите простенький интернет-магаз, который вы сами потом поддерживать не будете, а его допиливания фичами, масштабирование и прочее, в обозримом будущем не планируется. Вы вообще в один фалй можете все свалить, и бедет норм. Заказчику то как разница работает или нет. Тут ведь вопрос, не в том, зачем мучаться с написанием условной ddd, если можно сделать проще, а в том, будите ли вы это поддерживать и не пофиг ли заказчику (репутация, притензии, предъявы, всякое бывает).

Почему идёт такое противопоставление ddd и репутация, поддержка с одной стороны, писать всё в один файл/мешать бизнес-логику со слоем доступа к данным с другой?
Вы никаких вариантов кроме этих двух не встречали?
С примером про переезд как раз показательно. Звучит так, что если бы не ddd, то в любом случае надо было бы переписать половину кода