Иван Шумов

Выглядит как бред, пока не узнаешь что есть такая тема как Serverless) только реализация не такая. Хранить все-равно надо на диске, просто деплоймень происходит иным образом. А что касается базы так там можно хранить историю. Но вообще покажите вашему заказчику AWS lambda - пусть порадуется)

Clone создаёт новую копию объекта. В php объекты передаются по ссылкам, а иногда нужно их тиражировать.

Есть только один вариант - если у приложения есть какое-то internet-facing API. Приложения в самом смартфоне изолированы

Про производительность: Разница в языках по сравнению с тем какой код будет написан незначительная. Куда важнее кто и как пишет код. При масштабировании эта грань вообще стирается

Про масштабирование: этот вопрос не имеет ничего общего с языком программирования по тому как это абсолютно разные истории: код на любом языке программирования подготавливается примерно одинаково к масштабированию, а масштабирование это архитектура взаимодействия сервисов, добавление серверов, балансировка, репликации и всякое-всякое еще. Но это не про код

чем раньше тем лучше. этот процесс может занимать от нескольких дней до бесконечности - никогда не угадаешь

Никак. Скоропечатание это навык не для заработка денег, а для того чтобы их не терять, экономя время

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

Мне немного лениво разбираться, но, сходу, вопрос. Почему бы не пользоваться официальным sdk? м?

По тому что в большинстве своем это длительный процесс. Создаём где-то в фоне задачу, которая выкачивает нужные объекты, пакует архив и загружает во временный s3, отдавая ссылку на файл. В php не делать скачивание и запаковку - отдать задачу серверу. Если это все происходит в AWS то это можно сделать на lambda, sqs, или даже с применением stepFunctions. Можно много чего придумать. Там есть несколько ETL сервисов, можно подумать в эту сторону. Всегда есть вариант использования просто виртуалки. В любом случае синхронно это не слелать

Любой регистратор доменов это делает если домен действительно ваш. Если нет то только самому что-то клепать, наверное

В нормальных очередях если job не был выполнен то он сам вернется в очередь, даже можно настраивать когда. Что в Laravel там из коробки я не знаю, но логика, в целом, хорошая. Хотя я бы вынес наполнение очереди в отдельный механизм по тому как страниц может стать как больше так и меньше со временем, а такой алгоритм уходит в фиксированный цикл

Все системы, которые есть на рынке, имеют систему инвалидации как access token, так и refresh token. Это может сделать как администратор Identity Server так и сам пользователь. Что касается защиты от угона так тут те же самые рекомендации как и у всего остального

никак. сайты не зависят друг о друге и вообще не должны знать о своем существовании. Пользователи заходят и регистрируются через third-party сервис. То есть схема такая для простоты:
1. человек зашел на сайт, сайт его не опознал
2. сайт переадресовал человека на другой сервис (или же выдал форму регистрации/входа)
3. человек регается и логинится на этом ресурсе
4. сайт получает от этого ресурса защищенный токен и проверяет его
5. пользователь логинит у себя пользователя по токену
6. PROFIT

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