index0h

В полной мере - никак

Use CSP Luke!

Читайте про ffmpeg, сервера очередей (rabbitmq например), файловые хранилища (aws например), базы данных (mysql например), а так же серверные языки (php / python / golang / nodejs).
С помощью этих инструментов у вас есть возможность осуществить эту задумку. Обратите внимание на то, что конвертация видео - это трудоемкий и длительный процесс, так что вам нужно будет следить за тем, какой из серверов загружен сильно, какой нет. Ожидать что абстрактный сервер держит 5 потоков пересжатия не стоит, так нагрузка на прямую зависит от контента. 4к динамического видео с диким битрейтом и "как сохнет краска" в 720p будут нагружать сервера по разному.

Обращаетесь к руководству кинотеатров в которых это уже есть и покупаете.

Как сделать - начните с тз

Не используйте слово "просто" в адрес ПО, кроме ситуаций, когда являетесь автором.
То что эти проекты не выглядят в стиле word2003
с кучей кнопок, которые нужны 1.5 пользователям, как раз и значит что их делали не абыкак.

Wowza

Вы хотите того чего не надо хотеть. В фоне делается через очереди задач и отдельные процессы их обработки.
С точки зрения безопасности phpmyadmin на проде оставить - это себе же ногу отстрелить.

Авторское право не дает другим людям выдавать себя авторами произведения. Не более того. Это значит, что вы не имеете права выдавать себя за автора чужого произведения, но вовсе не значить что вы не имеете право его использовать. Однако авторство должно быть доказано и заверено, запросите документы, подтверждающие авторство на это произведение (код). Если таковые имеются и валидны с точки зрения вашего юриста - допишите на вашей веб системе до момента исправления, что используется чужой код и исправляете. В противном случае - шлите на йух, что произойдет с вероятностью 99%

Selenium

Вопрос из серии пальцем в небо.
Не меряется нагрузка в посетителях. Она меряется в rps и *bit/s. Также нужно знать прожорливость вашего ПО к io+ram+cpu иногда еще и gpu.
Количество серверов, способы распределения нагрузки, всякие репликации бд, распределения между ДЦ подбираются по конкретный проект.
Не бывает в природе такого, что вот так хренак и у вас откуда не возьмись 1кк активных юзеров, ну разве что событийные проекты типа прямых трансляций. Именно по этому рекомендую начать с малого, а дальше оптимизировать и распределять нагрузку между серверами там, где это необходимо. Например, у вас фото сток: cdn - это то, что вам потребуется. У вас месенджер - стоит выделить кучку серверов на поддержание сокетов с пользователями + хорошо прработать историю сообщений.

подскажите как на данный момент попасть в сферу веба.

Е*ашить по черному для получения опыта, причем на мелких конвеерных говнопроектиках опыта вы получите мало.

Просто уже 1.5-2 года не интересовался особо данной темой.

Это уже прошлый век))

И самое главное, как собрать портфолио?

Выполняете заказы, оформляете краткую сводку того, что делали. Вот это и есть портфолио.

Какие проекты сделать, чтобы не стыдно было приходить на собеседование?

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

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

У вас немножко искаженное представление о работе в web. Если вам это дело не нравится - это очень скучная, сложная, монотонная сидячая работа. А без опыта - еще и низкооплачиваемая. Рынок джунов перегрет, а на фрилансе у вас еще будет куча конкурентов из Индии. Во многих случаях первая работа - чисто за еду, для получения опыта. Учиться вам придется буквально постоянно, как только вы этот процесс приостановите - цена вашего часа работы сразу же начнет падать. С другой стороны вы не найдете ни одного синьйора, которого не прет его работа.
Все это я веду к вот чему: если вам не нравится - не теряйте время, попытайтесь себя найти в чем-то другом. DEV в IT - это не быстрые и легкие деньги.

у XXX.jpg и XXX.jpg?t=95683578 разный кэш

верно

как происходит разработка в реальном проекте. Как проходят этапы? Сначала фронт, потом бэк добавляется или наоборот или одновременно всё делается?

1. Постановка продуктового ТЗ. Это определение того, что собственно нужно сделать, например добавить на главную календарь.
2. Согласование этапов и правил взаимодействия, документирование api.
3. Постановка задач, для верстки, для фронта, для бэка.
4. Создание общей ветки на фичу.
5. Для каждой задачи - имплементация -> покрытие тестами -> код ревью -> вливание кода в основную ветку.
6. Разворачивание ветки на тестовом стенде, постановка задачи для QA.
7. Вливание ветки в master.
8. Релиз фичи на production.
9. Повторное тестирование QA уже на production.

Можете чтото отсюда почерпнуть Попросили проверить код, на что смотреть нужно?

Use symfony luke.

Для саппорта может подойти такое https://www.livechatinc.com

При этом, как Вы понимаете, нет цели изучить весь язык, стать супер-программистом.

Конкретно из-за этой строчки, то как вы хотите добиться результата - не имеет смысла.
Это тоже самое, что хотеть написать "абстрактную войну и мир", без знания языка.

вносит и читает периодически разного рода простые данные

Любая web-система оперирует разного рода простыми данными, в смысле вообще любая. Да, даже google

смотрит такую же простую аналитику, построенную арифметически на этих данных

Аналитика строится на базе большого набора данных

Рекомендую не использовать слово "просто", оно вводит в заблуждение прежде всего вас.

Или же брать Angular (который именно под SPA и заточен)

У вас данные должны будут где-то храниться, SPA не решает эту задачу

По пробуйте следующий стек:
- LAMP
- Yii2
- JS
- Vue
- Webpack
- Gulp

Ваш проект может занять несколько лет вашей full-time работы, будьте к этому готовы.

Я из тех людей, которые считают что "хочешь сделать хорошо, сделай это сам"

Сколько железа вы уже выплавили самостоятельно?))

Жуть какая. Ваш сервис будет деградировать с повышением нагрузки И повышением количества воркеров.

А теперь вопрос, как быть с массивами?

Наверное заюзать мютексы, которых нет.

Нода - это однопоточная штука, не надо эмулировать многопоточность. Вам же это еще и поддерживать.

Вполне нормальный кейс:
Кэш хранить в Redis, или чем-то типа того, ну а сервисы на ноде уже stateless.
Да, в такой схеме вы потеряете на издержках сети, зато получите простоту в горизонтальном масштабировании.

з.ы. посмотрите в сторону golang