Андрей К

Сделал бы на Express.js, но там тяжелые запросы к БД ожидаются, а в этих случаях ноду вроде использовать не рекомендуют.

Делайте. Вы неверно понимаете как работает node.js. Наоборот, если у вас тяжелые запросы, то node.js это то, что нужно. Ввод/вывод в node.js неблокирующий, это значит, что вместо ожидания ответа от сети или файловой системы, вы сможете обслуживать других клиентов.

Не рекомендуют использовать node.js для сложных математических/физических и тому подобных расчетов требовательных к процессорному времени, что соответственно будет блокировать процесс пока процессор занят обсчитыванием этой задачи. Что вообще ни разу не про веб. И даже в таком случае, можно разделить такую задачу и выполнить её за несколько тиков или даже в дочернем процессе.

Никакая чудо-оптимизация, если бы она даже была, не сделала бы Photoshop, работающий в виртуальной машине под Windows поверх любого Linux, быстрее.
Не занимайтесь ерундой, купите оперативки побольше.

Можно брать вообще всё что угодно. Главное обозначить какие минусы получишь и насколько они критичные если заюзаешь некую "технологию Х". Ну и наоборот, какие плюсы и насколько весомые.

1) Насколько критичны 20 метров на харде?
2) Насколько критично 20мс на ларку, вместо 10мс на нативе?
3) Насколько высока вероятность появления новых тасков? Вроде нотификаций при нажатии на какие-нибудь кнопочки. Или запилить админку под это дело.
4) Ещё что-нибудь.

Если считаешь что-то очень важным, то это повышает приоритет использования какого-то подхода. По-мне, вероятность появления тасков в нашем мире скрамов и аджайлов намного выше, нежели то, что на сервере будет только 15 метров свободного дискового пространства...

Хорошее техническое задание -- очень обтекаемый термин. "Хорошим" можно было бы назвать техническое задание, отвечающее некоторым требованиям. А вот уже эти требования в зависимости от масштаба разрабатываемого продукта, методологии разработки, заказчика/исполнителя и других факторов могут сильно отличаться.

Так, например, если вы работаете с государственным или окологогосударственным заказчиком/исполнителем, весьма вероятно, вам придётся подготовить ТЗ в соответствии с требованиями ГОСТ-19 и 34 (в особенности ГОСТ 34.602-89 и ГОСТ 19.201-78), которые предполагают создание очень формальных и подробных документов.

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

Для какой-нибудь дизайнерской разработки (стиль, лого, графика), когда велика изначальная неопределённость, что же требуется сделать, лучшим вариантом может являться вообще достаточно общий бриф.

Резюмируя: определитесь с требованиями к ТЗ, а, отталкиваясь от них, уже можно искать какие-то варианты.

Хорошо бы знать, что у вас за проект и какие задачи он решает.

на выходе мы получим огромный бандл из всех модулей

- это почему же так?
А webpack для чего придумали? vue cli 3 вроде как из коробки вместе в webpack уже умеет всё разделять на модули, ну и вам самим никто не мешает сделать полностью модульную структуру так, как вам хочется, вручную настроив сборку проекта.

Для большей наглядности, как пример, можно разобрать приложение CRM, где одним нужна только страница выгрузки отчетов, а вторым, скажем, аналитика продаж.

Есть ещё nuxt.js в котором сделано ещё больше для модульности, там модули все загружаются тогда, когда они реально нужны. Т.е. у вас 10 страниц, у каждой своя логика, на пол мегабайта. При заходе на сайт, логика 10 страниц не будет загружена, а лишь тогда, когда вы зайдёте на страницу. Ну и опять же, никто не мешает и там добавить своих правил для webpack, если что-то не устроит. Следовательно, если определённому типу менеджеров нужна лишь определённая часть сайта, то зайдя на нужную ему страницу он загрузит логику этой страницы, но не десятка других.

А верстать всё это вы как собираетесь?
А раз это мини сайты в одном большом сайте, как вы собираетесь делать общие стили и компоненты?

То есть, для каждого модуля свои vuex, router

- ну а кто мешает вам на файлики разбить хранилище и роутер?

У vuex есть свойство modules - куда и импортируем модуль хранилища
У Router по сути тоже самое https://stackoverflow.com/questions/46590760/vue-j... вот статья для примера.

Ну и всё же, даже если всё вот так разделить, где целиком отдельные spa друг от друга, а как вы связывать их собираетесь 1 целое?
Типа написали плагин и что, теперь его во все 10 разных модулей подключать?
Типа, есть шапка, одна на весь сайт, создал компонент, что, тоже ходить и в каждый подключать?

Ну, так должно же быть у них что-то общее между собой, делающее всё это единым сервисом.
Как бы да, есть яндекс, который сумел создать единый UI для своих проектов, но и проекты у него никак не связаны между собой, а если и связаны, то не сайты друг с другом, а как бы общая база яндекса связана с проектами.
Как я понял, в вашем примере, модули - это яндекс музыка, карты, новости и т.п. Зачем всё это объединять в 1 проект? ИМХО Если я так понял, то нужно не просто отдельные модули делать, а отдельные сайты.

К сожалению, я слабо понимаю, что у вас там за ВАСЯ иентерпрайз, что бы в целом посидеть и подумать + я так и не услышал в вашем вопросе доводов архитектуры ваших коллег.

Маленьких лайф-хак

Когда вы учите новую технологию, сразу держите в голове, где вы её хотите применить, либо где вы хотите на ней работать.

Я когда учил Django, открыл вакансии (на которые меня могли бы взять), посмотрел, что за компании. Она мне понравилась. Увидел, что у них есть открытое АПИ для интеграций с ними. В итоге, написал небольшой сервис, который работает с их АПИ.

В итоге, на собеседовании было просто - изи. Показал им свой сервис, тем самым сразу показал, что знаю нужный стек, и знаю уже частично их сервис и апи - в итоге, получил офер.

См. вакансии вас интересующие (например, на hh.ru).
См. требования к вакансиям вас интересующим.

Как вносить изменения в сайте без бекэнда?

используя html, очевидно же

Новый массив нормальный, да. Старый массив продолжит существовать пока на него есть ссылки. Если на него никто не ссылается, то он еще чуток поживет, а потом его сборщик мусора удалит.

В вашем примере на него ссылается collection, но если удалить collection, то и старый массив удалится.

Вот вам такой примерчик:

Выбираю из 16 или 32?

У меня при веб-разработке одновременно запущенны: Chromium, Avocode, VS Code и Gulp. В сумме эта четвёрка отъедает 3.5 Гб ОП. Вывод: мне и 8 достаточно.

Так, а в чём принципиальная разница с TCP то? Там же ещё проще должно быть: не нужны никаких обработки коннектов, отваливаний, стриминга. Шлёшь себе втупую датаграммы, когда сокет свободен, и принимаешь — когда буфер не пустой, и не паришься.
И почему не нравятся библиотеки? В них же за вас уже все косяки и баги порешали. А их там, поверьте, хватает. Где-то poll тупит, где-то нет epoll, где-то файловый IO ещё вешается нормальный. В винде вообще IOCP вместо всего этого используется, и тот через жопу.
И, разве, в man epoll нет примера? В своё время мне хватило его, насколько я помню.

Выделить имена собственные в тексте - задача нерешаемая без распознавания контекста. Например "новый год" - имя собственное, если речь о празднике, но имя нарицательное, когда говорится о новом календарном периоде.

К Yii2 должен прилагаться программист. Собственно в вашем случае программист в любом случае должен прилагаться. Он и выберет.

Ну во первых - забудьте про использование php при таких количествах данных. Php не самый оптимальный вариант когда кол-во оперативной памяти ограничено. Здесь гораздо лучше использовать тот же mysql-client или mysqldump. Естественно вставлять лучше одним запросом. Во вторых - саму СУБД тоже надо подготовить к записи такого кол-ва данных. Этого обычно нигде не пишут, но mysql не пригоден для использования "из коробки". Для начала можно попробовать отключить бинарный лог(если нет необходимости в репликации и т.п.). Это освободит драгоценные иопсы на ЖД, особенно если на сервере присутствует не только одна база данных. Если таблица innodb(или его форк) - то настроить необходимые переменные этого движка(количество потоков записи, размеры всяческих буферов, логирование транзакций и т.д.) исходя из возможностей сервера. Все вместе по итогу даст и прирост скорости выполнения запроса и оптимизацию использования серверных ресурсов.