d-sem

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

Самое универсальное решение это поднять на nodejs сервис на базе puppeteer https://github.com/puppeteer/puppeteer и переложить на него всю ответственность по парсингу динамических страниц. А в него уже передавать запросы.

С точки зрения php теоретически можно попытаться разобраться в хитросплетениях API запросов, если на целевом сайте вдруг совсем не делали защиту парсинга. Можно подключить любой компонент для headless браузеров.

Но с точки зрения кпд и качества лучше всего сделать сервис на инструментах которые изначально для этого заточены. Связка nodejs + puppeteer с отдачей данных по api (http или очереди - rabbitmq в rpc) это очень мощное и в то же время простое решение. Хотя бы просто потому что puppeteer это оболочка над google chrome, которую очень удобно дебажить в консоли браузера.

Если непонятна документация, то это означает, что либо документация плохая, либо есть пробелы в фундаментальных знаниях. В обоих случаях для понимания нужно изучать базовые вещи, на которых эта документация основана.

Если что-то не ищется в интернете, то скорее всего ищется неправильно или на неправильном языке. Или оба варианта вместе. В англоязычном сегменте гугла можно найти ответы на все вопросы.

В такие моменты обычно и пригождается хорошее высшее образование для организации научного поиска и структурирования информации, а также для экспериментов.

Пробовать все - нормально.
В какой то момент, что-то да захватит. Возможно, просто еще не найдена своя ниша.

А с концентрацией - скорее всего вопрос целеполагания. Если поставить цель сталь джуном в каком то направлении и идти к ней - то все будет ок. А пока все делается добровольно и по настроению - такие перескакивания и будут.

Мне лично помогло не размазываться осознание того что у меня скоро закончится финансовая подушка и никто мне не поможет. А семью нужно кормить и счета платить. Знание даты когда у тебя кончатся деньги и тебе нечего будет есть - очень мотивирует стать джуном :)

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

Поэтому выход в архитектуре. Асинхронность реализуется через очереди, а снижение нагрузки через кеширование.

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

Пример:
1. Точка API где собираются результаты паралельных запросов - Node.js с промисами которые работают с очередями для общения с п.2 и п.3, при необходимости в будущем переписать на golang, если будет тормозить;
2. Точки где не нужны высокие нагрузки и много логики - php, python, любой язык который хорошо знаете. Если будет что-то становиться узким местом - переписывать компилирируемое и оптимизировать;
3. Где высокая нагрузка - что-то компилируемое вроде golang.

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

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

Например, у Вас может быть супер защищенный сайт, но рядом у вас в соседней папке у вас лежит приложение, которое принимает команду из пользовательского ввода и подкладывает ее в exec(). Или веб-сервер настроен так, что по отдельным запросам на другие виртуальные хосты отдает содержимое конфиг файлов. Или ньюансы срезания углов при разработке (добавим более тщательную фильтрацию полей позже. ага). Или внезапно выяснилось что в версии вашего ЯП, конкретной библиотеке или субд есть фундаментальная уязвимость.

Хотите комплексно подойти к вопросу? Копайте в сторону изучения материалов от OWASP. Например, https://owasp.org/www-project-web-security-testing... Там достаточно много материалов для чеклистов. Или смотрите готовые чеклисты что проверять. Например, https://github.com/0xRadi/OWASP-Web-Checklist (я не говорю что это прям лучший чеклист, но посмотрите на число пунктов для быстрой оценки).

Хотите подойти еще комплексней? Начните с книги для новичков по поиску узявимостей - Ловушка для багов. Полевое руководство по веб-хакингу | Яворски Питер https://www.piter.com/product_by_id/196618476

А далее например обратите внимание на более сложную книгу как строить защиту в приложениях
Безопасно by design | Берг Джонсон Д., Деоган Д., Савано Д. https://www.piter.com/product/bezopasno-by-design
Там уже более основательно доводится доводится мысль как выстраивать защиту на основании архитектуры.

Согласно документации внешнего сервиса построить ожидаемые ответы. Например, если есть OpenAPI | Swagger, то достаточно просто подменять ответы по разным путям.

А в месте где происходит отправка запросов добавить параметр - отправлять реальный запрос или получить локально сохранённый ответ или вообще генерировать эти ответы на основании документации.