Алексей Колосов

Не знаю, насколько подойдет, но встречался мне такой чат Total.JS Messenger - вполне себе годный, вроде все что нужно есть (остальное допиливается разработчиком на node.js при желании). У разработчика фреймворка также можно заказывать вроде премиум-поддержку, так что в случае отсутствия своего разработчика можно обратиться напрямую.

Все зависит от того, какую базу данных вы используете.
В некоторых базах есть так называемая подписка на изменения данных или фильтр на обновленные данные.
Также мне видится небольшая логическая несостыковка - у вас выводит 10 последних новостей, зачем перегружать логику приложения фильтрацией на загруженные или незагруженные новости, если все равно выводит 10 последних?
Ну я просто не понимаю вашей идеи видимо, вот был блок с 10 новостями. Сделали запрос, новых нет - блок пустой что-ли теперь? Или если новых 3, блок будет состоять только из этих 3? Или все также 10 последних? Если все также 10 последних, какой смысл усложнять запрос на сервер и в базу данных, если все равно вернется 10 последних?

Вся вселенская боль, что сравнивать Яп в рамках сферического вакуума (то есть без конкретной задачи) - ну просто пол-палец-потолок.
Основной момент у вас - что из себя представляет собой алгоритм и какова его сложность.
Допустим (пол-палец-потолок) - это анализ текстовых данных. Берете Perl.
Или обработка статистических данных. Ну тут наверное Python ?
Короче смотрите на специфику алгоритма и выбирайте из ЯП, которые больше подходят по эту сферу.

Чтобы это выглядело именно как репозиторий npm - то вот вариант https://www.npmjs.com/package/npm-mirror
Но сразу все пакеты, боюсь вы не сможете никак скачать. Только те, которые нужны для проектов.
Возможно проще скачать там, где есть интернет и просто принести папку node_modules на флешке.

Лучше всего воспользоваться базой данных. Сейчас практически в любой можно реализовать Time To Live, по сути - срок жизни записи.
В комментах вы пишите, что запросы будут приходить часто и много - в этом случае действительно с файлом могут возникнуть проблемы.
Если вас смущает накладные расходы на обращение к данным в БД - прочитайте про IN-MEMORY. В MySQL кстати оно есть (не помню в какой версии, в MariaDB 10 точно видел упоминание).
Лично я бы взял Redis и работал бы с ней, благо данных не много, ОЗУ много не потребуется. А работает она очень быстро. И функциональность достаточная, что потом может пригодится для хранения других данных или например для реализации очередей, хранения сессий, оповещений и т.п. А TTL там заложено на уровне движка - добавляете запись, при добавлении можно сразу установить срок жизни в секундах и запись сама удалится по истечении времени. А можно без указания TTL (в 0) и тогда запись не удалится.
Так и вижу - заносите доступные пин-коды с TTL=0, а когда их активируют - указываете для записи TTL нужной длительности и с момента первой активации начинает тикать счетчик. Удобно же и никаких велосипедов изобретать не надо. С Redis работать просто почти в любом ЯП сейчас, очень простое и легкое API.

Certbot хранит свои конфиги в /etc/letsencrypt обычно. Удаляйте ненужные домены в renewal и все ок будет.
Если хранится все в одном домене - ну тогда удалите его и заного сгенерируйте как вам надо.

Фига се мало. Везде докручивают этот C#, всякие Mono и т.п. А вы типа "мало кто особо хочет". Хочет хочет и пользуется, когда надо.
Нормально засуетились, предполагаю, что из-за растущей популярности Node.JS (чисто мое мнение). Но это не значит, что будущего нет у .NET - есть и еще лет на 10 точно хватит

Более перспективно в вашем случае мобильные разработки - более узкий спектр, зарплатные рамки в основном выше, востребованность хорошая. Особенно для iOS и удаленно за рубежом, хороших спецов не так много. Да и у нас сейчас это вполне прибыльное дело, как под iOS, так и под Android.
Веб разработку выучить легче, но спектр гораздо более широкий. На мой взгляд рынок перенасыщен "спецами", готовых сделать все быстрее и дешевле, успеть выманить у которых заказ намного сложнее. Поэтому пофрилансить по вечерам - даст профессиональный рост, но никак не заработок, на первых порах точно.
Единственный плюс веб - если очень хорошо выучить JavaScript и поднатореть во фрейморках node.js, Electron, React, Vue и т.д. - можно закрыть всю сферу от сайтиков до мобильных и десктопных приложений разом. Но сложна.

А я думаю самый богатый опыт получите при разработке игрового проекта. Браузерная игра любого типа. Тут и работа с БД и с правами и интеграция с внешними сервисами (типа авторизация через соцсеть) и вопросы оптимизации и вопросы валидации верстки и вопросы обмена информации между клиентом-сервером и т.п..

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

GIT умеет хуки, которые могут запускаться в том числе при получении коммита.
По хорошему у вашего процесса разработки сервиса должны быть три этапа - dev, stage, production.
То есть dev - это вы работаете, к примеру со своей копией кода у себя на компе. Также это когда тот разработчик у себя работает с копией кода. То есть каждый из участников каким либо образом поднимаете у себя локальную копию приложения (целиком или отдельных частей, я хз что там у вас за приложение). Особых пояснений не надо, надеюсь? Обмен данными через какой-либо репозиторий происходит, тут вы правильно мыслите. Вы исправили, отправили коммит - разработчику сообщили, тот скачал себе и от себя что-то там натворил, результат в репозиторий и т.д. по кругу.
Для этапа stage - обычно подразумевается окружение (сервер), максимально приближенное к тому, где будет работать приложение. Но все же это тестовый вариант, на нем вы вместе с разработчиком отлаживаете окончательную версию перед выкладыванием на рабочий сервер. А после того, как все работает, отправляете код на рабочий.
Способов "налету синхронизировать" множество. Почитайте про GIT HOOK, возможно это то, что вам надо. Там можно написать скрипт, который, например по коммиту с определенным тегом поднимает тестовую реализацию приложения и отсылает данные по доступу разработчикам.
Также можно использовать специальные хостинги, типа Heroku, где процесс достаточно автоматизирован и удобен.

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

Для работы приложения на node.js нужна собственно среда node.js на сервере, без нее код не будет работать никак.
Практически всегда веб-приложение на node.js уже запускает свой вебсервер, это действительно хороший вариант и производительный. Никаких прослоек, обычно не требуется. Иногда поверх пускают nginx, так как он лучше справляется с отдачей статики (например css, js и картинок).
В вашем случае, так как порт для сайтов уже занят Apache, то вам достаточно создать в нем вхост, где сделать прокси на порт, на котором будет работать ваше приложение на node.js. При этом напрямую доступа Apache к папке с файлами приложения иметь не обязательно (да и не нужно, лишняя дырка).
В идеале конечно следует избавиться от Apache в пользу nginx. Так как Apache будет создавать узкое горлышко для производительности приложения на node.js

Для начала вы определитесь, что и в каком объеме будет хранить база данных (хотя бы примерно)? Какие требования у вас к БД, к ее производительности, к ее возможностям, наличию возможности удаленного доступа и т.п.?

Если вам там нравится JSON - посмотрите в сторону NoSQL баз данных. Например, MongoDB. Схема хранения данных схожая, гибкости больше и это СУБД, отсюда всякие ништяки типа отдельного доступа к БД из других приложений, встроенные средства работы с данными, сортировкой, индексами и много чем еще, типа архитектурно заложенные средства безопасности, транзакций и т.п. и т.д. и др. В очень грубом приближении можно сказать, что это MySQL (нет конечно же), но подход к хранению и обработке данных совсем другой.

Есть также несколько реализаций встраиваемых БД, которые не требуют установки на сервер отдельного программного слоя в виде СУБД и работают на уровне самого приложения (неважно, сайт в том числе). На разных языках программирования есть и универсальные и уникальные реализации. Например, NeDB для node.js, LiteDB для .NET, LevelDB, PouchDB и т.п.

Если у вас будет немного данных, всю базу можно и хранить в файлах, как вы описываете INI или JSON. Разве что выбор INI не то, чтобы неудачный, просто почти в любом веб-ориентированном языке программирования есть уже средства по работе с JSON. В том числе и реализации встроенных баз данных на базе JSON. Успешных реализаций встроенных баз данных из INI я не встречал еще... Тем более, что в конечном итоге вам наверняка придется обмениваться данными между сервером и клиентом и для этого обычно используют именно JSON.

Хранение большого количества мелких файлов (в вашем понимании INI) - может стать в определенный момент проблемой на уровне операций с диском, также все сильно зависит от файловой системы и ее настроек на сервере. 50 тыс это дофига на самом деле. Я встречал проблемы с более 30к файлов в одной папке, решить это потом "на горячую" будет проблематично, а главное что не всегда будет очевидна проблема.

Мне сразу кидается в глаза несколько исходных недочетов. Если берете на вырост, то....
Берете самую дешевую планку DDR4, одну на 8ГБ. Вполне достаточно даже Silicon Power, работать будет не хуже Kingston. Сейчас вам не нужны свистоперделки и красивости, а для такого процессора и двуканального режима памяти. Потом, в процессе роста, добавляете еще планки, у вас начинает работать двуканальный режим памяти и есть место для еще 3 планок.
На сэкономленные деньги вместо 128ГБ SSD берете 256ГБ, желательно от Samsung. Лишними они точно не будут.
Жесткий диск WD Black 2.5" - вы серьезно? Берете нормальный 3.5" от того же WD, только Blue, за ту же цену можно подобрать 2ТБ на 5400, по скорости он будет практически не уступать вашему варианту. Да и в целом вам для всего хватит, это я вам как пользователь серии WD Green говорю, которая слабее. Зато шуметь будет на порядок меньше, чем 7200.
Дальше...
Если планируете разгон, то есть потом когда нибудь поставите процессор с литерой K. То рекомендую вместо материнки MSI брать на том же чипсете что-нибудь на Asus. Некоторые люди пишут, что с разгоном MSI иногда портачит.
Блок питания Aerocool VX - тоже считаю не очень, если уж и этой фирмы, то из серии KCAS, а лучше Seasonic или Chieftec.
Корпус.... Ну такое себе решение, я бы взял лучше самый дешевый NZXT Phantom 240 - он и покачественнее скорее всего и внизу нет этого дурацкого короба, мешающего нормальному притоку воздуха.