Dr03d

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

Поэтому желание сначала "всё сделать так", а потом "всё сделать наоборот" - неверное.

Верно сделать монолит, а потом те части которые постоянно в деле - вынести на другую машину с этим самым апи. Авторизацию, социальный модуль (это тот который друзья друзей друзей друзей по графу постоянно рассчитывает), можно платежку тоже отдельно, чтобы ожидания меньше были. Не надо делать ВСЁ отдельно, чтобы оптимизировать.

Сначала всё пишется в "синхронном коде", по мере того как появляется код который должен быть выполнен строго после того как бизнеслогика отработала, т.к. несет за собой последствия, которые потом надо откатывать - появляется "асинхронный код", который представляет собой обыкновенный while (true) в конце когда и кучу \Closure в виде цепочек (то есть они выполняются не в глубь, а в ширину 10 очередей - 10 функций одна за другой, шаг while (true), осталось 5 очередей (5 завершилось) - теперь 5 функций одна за другой, которые ставятся в очередь, используя promise (да, в пхп тоже так можно, причем если вы используете \React\Promise библиотеку, то вы получите обход вглубь, но это неверно, и ведет к нарушению порядка выполнения действий, нужно сначала десять первых уровней, потом десять вторых, тогда как промиз сделает для вас 1-2-3-4-5, следующий 1-2-3-4-5, смысл в том, что третий из первого может хотеть второй из второго например).

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

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

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

Худшее, что вас ждет - это создание диспетчера фоновых воркеров. Это такая хрень, которая очень напоминает пхпшную функцию debug_backtrace() только вы реализуете её сами из тех задач которые делаются по апи. То есть вы не делаете запрос "http GET", вы ставите задачу "http POST" (запись в лог, событие), через какое-то время задача стартанула (запись в лог, событие), задача выполнена (запись в лог, событие), задача провалилась (запись в лог, событие), и так для каждой задачи, а задачи по сути ещё одна другую могут запускать.

То есть это не обязательно стоит делать для авторизации, которая должна быстро отрабатывать, но когда начинают играться с "много серверов" творят именно такую чернуху.

В принципе есть написанные штуки вроде даже приемлемого качества типа Temporal (хотя они предлагают организацию именно фоновых запусков приложений, а не фоновых приказов десятку машин), написанный командой Spiral. У Spiral не лучший код в мире, но качество уровня симфони они дать могут.

Думаю, что подключать сюда ИИ нету особого резона, как мне кажется.

ну да, конечно

— В некоторых языках мира двойное отрицание означает согласие. В других, двойное отрицание так и остается отрицанием. Но нет ни одного языка в мире, в котором двойное согласие означает отрицание.
Голос с задней парты:
— Ага, конечно...

ИИ и еще раз ИИ, гоняют корпуса
проблема с тем же украинским и прочими казахскими и прибалтийскими - корпусов мало

к слову, год так 2018й про переводчики - ИИ окончательно обошел правила, говорилось кажется о EN ES - эта пара проблем не испытывает,
в целом все на уровне, это видно уже по всему - от Дипла до Лингвалекса

а вот с иероглифами - бЯда, чайна еще +-, хотя всем видно что смИшно, а корея - вообще мрак

с грамматикой, конечно, подобная бЯда - живой язык опережает корпуса, и уж совсем не в классике

Давным-давно, еще в советские времена, буфетчица из московского Дома литераторов жаловалась подруге: «Какие они все-таки безграмотные, эти писатели! Подходят и просят: «Дайте одно кофе, дайте одно кофе!». Один только Расул Гамзатов (народный поэт Дагестана — Л.В.) всегда говорит: «Мнэ адын кофе!». А потом добавляет: «И адын булочка!».

а году в 2010-15м кофе разрешили быть одно, точнее, и один и одно

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

ну и конечно есть набор правил, но у него полно ложноположительных срабатываний

stackoverflow.com/questions/17610783/nginx-web-dav...

функцию swa() забыли привести, как вы начали её писать?

В неё перым аргументом попадёт объект Event, у которого есть свойство target – элемент, по которому кликнули. В данном случае это тег <a>

Для этого элемента можно найти родителя (свойство parent) – это div. А в нём уже найти элемент H3:

const title = event.target.parent.querySelector('h3').innerText;

1. Джаваскрипт ничего не знает о php и laravel. Пропишите его явно или каким-то образом прокиньте в js.
2. Для регистрации нельзя использовать гет параметры. Регистрация меняет состояние, вы создаёте пользователя, потому надо использовать POST. Кроме идеологических причин, есть ещё причины безопасности и багоустойчивости. Гет запросы логируются и кешируются.
3. Зачем в 2022 году продолжать для таких запросов тащить jquery, если браузеры поддерживают fetch https://learn.javascript.ru/fetch

Сделайте rewrite правило в конфиге nginx, чтобы при обращении к sitemap.xml вызывался php скрипт, который и обновит и выведет содержимое sitemap.xml. Только позаботьтесь о некой логики кеша, чтобы функция обновления файла запускалась не каждый раз, а по мере устаревания файла или его отсутствии.

Прекрасный повод пересмотреть парадигму "начинаем работать на компьютере с офиса".
Не искать костылей, которые заменят привычные костыли Excel+VBA, а разрабатывать решения, которые не зависят от желаний левой пятки корпораций и правительств.
Например, Javascript на HTML-странице позволяет не только корректно повторить весь расчет, который народ шаманит в Ёкселе, но и читать-редактировать его без чудовищного геморроя с прыжками по ячейкам и мучительными попытками вспомнить, в которой что считается.
Нужно не только расчитывать данные, но и хранить их? База данных на Линуксе поднимается за 10 минут и не стоит вам ни копейки. Нужно обмениваться данными? JSON и XML не требуют никаких конкретных программ конкретной версии - ваша информация остается доступной, даже если вся M$-продукция объявлена вне закона...
Нужны документы для печати? PDF - открытый формат, и документ в этом формате не перекосит от того, что вы открываете его не в той программе, в которой создали. Более того - полно библиотек, которые автоматически создадут вам этот документ из ваших данных.
Нужно только сменить парадигму. Для будущего.

Инкапсуляция вообще является (ИМХО) главным принципом из 4. Инкапсуляция + абстракция. Вы не поняли её основную идею. Инкапсуляция это объдинение в одной сущности данных (не обязательно в общем-то) и действий которая эта сущность может предоставить. Инкапсуляция + абстракция представляю собой в общем более общий принцип - сокрытие информации/сложности, и один без другого не сильно то полезен. Не путать с модификаторами доступа (public, private и тд). Этот принцип идет скрозь всю историю развития языков программирования и собственно является главной движущей силой их развития. Вот пример из реальной жизни: есть у вас микроволновка. Она имеет +- 2 нопки: выставить время, выставить мощность. Это интерфейс микроволновки, который доступен конечному пользователю. Всё что вам нужно знать, чтобы приготовить себе похавать - 1)на какой мощности это хавать, нужно готовить 2) сколько это нужно делать по времени. При этом очевидно внутри микроволновки происходит та самая сложность, микросхемы гоняют электрический ток, магнетрон изучает электромагнитные волны, всякая разная физика происходит и вот это вот всё. Итого: вся эти физика и электротехника инкапсулирована в объект микроволновки (инкапсулирована так, что мы не можем добраться до её внутреннего устройства, это важно. Т.е. мы не можем сами соединить проводки, поменять электрическую цель, чтобы себе похавать сделать, разработчик этой электропечки не дал нам даже потенциальную возможность это сделать легально. Можно конечно разобрать устройство и проделать все эти манипуляции, но это уже это на совести того самоделкина, кто это делает). Итого: мы имеем интерфейс из двух кнопок и получаем от обьекта микроволновки услугу - приготовить пожрать. Как там внутри это реализовано, нам не важно. Это и есть инкапсуляция + абстракция = сокрытие информации/сложности.
Более программистский пример: есть такая структура данных - Стек. Хотя по факту это не структура данных, а абстрактный тип данных. Советую этот термин загуглить, это важная составляющая в понимании ООП.
Представим, что стек это такой обьект который предоставляет услуги, по типу как мы представляли себе обьект микроволновки. Что нам нужно знать про стек, чтобы им пользоваться? Публичный интерфейс. Т.е. есть класс Stack с публичными методами push(), pop(), viewTopStack() (посмотреть первый элемент стека, без его удаление из самого стека). Всё, можно пользоваться. Как он внутри эти элементы хранит, простой ли это массив, или связный список, на сколько эффективно он там внутри работает - нам не важно. Это важно тому, кто предоставил нам в пользование данный класс. Мы знаем, что вызвав viewTopStack мы посмотрим первый элемент стека, вызвав push - положим что-то в стек, вызвав pop получим первый элемент, удалив его из стека (по аналогии: мы знаем что чтобы притоговить пожрать, нужно выставить в микроволновке время и мощность, на выходе получив наше адово хрючево). Если подытожить - инкапсуляци + абстракция, (еще раз настою на том, что порознь их нельзя рассматривать, это две тесно связанные концепции которые имеют практический смысл только в синергии) это механизм борьбы со сложностью, не только в программировании, вообще везде, в любой человеческой деятельности. В этом их смысл. Если ваши абстракции плохие -> ваш код сложный -> ваш код плохой (говнокодом его еще называют в сообществе программистов).
Почитать на эту тему можно следующее: Р.Мартин - Чистая архитектура (начать с глав про SOLID прицнипы), С.Макконел - Совершенный код (главу про классы обязательно, остальное желательно (очень желательно)), там в общем-то вам расскажут то что я вам сейчас рассказал, только более подробно, по больше примеров и дадут обоснование сложности, назвав борьбу с ней - Главным техническим императивом. Шлифануть это книгой банды четырех. Сами паттерны не обязательно начинать учить (да и рано вам еще), но вот введение и часть про программирование на основе интерфейса, а не реализации - самое оно, это дополнит картину.

UPD: тот факт, что мы в классе стек собрали его функционал (функции pop,push,...) обьединенные одной общей темой и есть факт инкапсуляции.

Инкапсуляция действительно защищает - мозг программиста от переполнения. И только.
Машинный код после компиляции класса, в котором методы и члены объявлены private или public - один и тот же.
Они нужны только для автоматической проверки компилятором - не ошибся ли программист.
А инкапсуляция - это не столько собирание в одну кучу того, что работает вместе, сколько обрывание любых связей с остальным кодом. За исключением реально необходимых. После чего класс становится вещью в себе, и вам можно работать с ним, не задумываясь о прочем коде, и работать с прочим кодом, не думая о потрохах этого класса.

Какой именно интернет вы весь перекопали?
Первая же строчка по запросу в гугле "unreal engine developer roadmap", например - не устраивает?
Может, вам и не стоит в С++?..

приходится говорить что-то типа: ну вот у тебя зависит от него, ты посмотри как у него сделано, поставь заглушки, потом объедините.

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

А так это надо на конкретной задаче разбирать, в чём затруднения. "По фотографии" такие проблемы не решить.

Дробить задачу еще на более мелкие совсем не охота

Ну и зря. Вообще-то технологиям планирования совместной работы уже не первый век, и важнейший этап - как раз выделение тех участков работы, которые критичны для начала работы на других участках, и подтягивание их на диаграмме Ганта как можно раньше, чтобы уменьшить простой. Потом уже менее критичные задачи ложатся на свободные участки и параллелятся относительно друг друга.
Так, например, нас учили делать генплан строительства еще 30 лет назад. До популяризации в РФ всяких там Скрамов и Канбанов.

Ответ на этот вопрос можно получить либо экспериментально либо изучив серверную реализацию (в конечном счете тоже экспериментально).

У тебя 2 основных узких 'горла' - скорость подготовки ответа сервером (процессор и диск) и скорость сетевого соединения до него... ну а медленный клиент можно распараллелить несколькими машинами (и соответственно провайдерами если проблема в сети на стороне клиента).

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

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

Ну и вишенка на торте, транспортный уровень может внести корректировки, полистай статью

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

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

Ну и нагрузка на процессор, если реализация однопоточная (асинхронная реализация сильно усложнит подсчет) то скорость ответа будет линейно зависеть от времени обработки одного и нагрузки на процессор (проще замерить сколько клиентов дадут 100% нагрузку). Но вот многопоточные реализации могут давать неожиданные ухудшения характеристики, т.е. 10 потоков могут не дать 10-кратное увеличение скорости, и с величением потоков будет много ресурсов уходить на поддержание этой работы (кажется теория вообще говорит о квадратном корне из количества потоков), и это еще про кеш процессора речи не идет, так как в зависимости от того, влезает ли алгоритм обработки (нужная ему память) в него или нет тоже можно получить кучу странностей, например 1-2 потока будут давать быструю скорость, но добавив третий, даже не нагрузив весь процессор, можно получить значительное понижение производительности, так как данные трех потоков не влезают в кеш. Кстати оперативная память хоть и называется Random Access memory но может давать разную производительность в зависимости от характера нагрузки (особенно это видно по вычислениям на GPU) что тоже не лучшим образом влияет на многопоточный результат.

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