Александр Талалаев

Советую все брейкпоинты самому по минимуму придумывать, а брать у лидеров:
https://getbootstrap.com/docs/5.1/layout/breakpoints/
https://tailwindcss.com/docs/responsive-design
Изучи какие они используют, смело бери их к себе в проект.
Ну и конечно же лучше идти снизу вверх, те по умолчанию у тебя мобильная вёрстка, в брейкпоинтах пишешь то, что отличается у тех кто больше.

Да конечно, абсолютно нормально так делать. Можно использовать разные техники чтобы замокать API, от простых быстро запущенных ответов заглушек на бекенде, до всяких инструментов вроде https://restapify.vercel.app/ который поможет быстро всё сделать.
Главное вы в проекте должны утвердить сам API, методы, ендпоинты и тп и тд,

Если у вас огромный трафик и стоит задача решить проблему снижения объемов то да. Нужно думать как генерировать webp, с учетом обратной совместимости и тп. Сейчас ему на смену готовится выйти еще больше оптимизированный AVIF(он на основе нового видео формата), который скорее всего его победит, как более универсальный и менее привязанный к Google.
А так помним. Любая работа это деньги и время. Может вам лучше вложить это в другие, более важные для вашего проекта направления?

Начну с того, что если вы таки активный разработчик и не очень можете понять этот принцип, возможно он вам просто не нужен. И это не значит что вы плохой разработчик, просто не пересекались с таким видом проблем.
Что касается serverless, название больше отражает не факт отсутствия сервера и работы с ним как таковым, а скорее еще меньше возни с настройкой и поддержкой серверного окружения (даже меньше чем с докером после того как все настроено и поднято). Те это следующие шаг после условных микросервисов.
Его часто удобнее называть функция как услуга, так как де факто часто реализуется запуск именно функции по запросу.
Если кратко описать для чего это нужно, то представим себе что у нас есть микросервис у которого затраты на содержания его постоянного аптайма как то слишком велики относительно времени работы/потребления ресурсов в живую. Да и в целом сервис выходит как то слишком микро даже для микросервиса.
Вот тут мы и придумываем такую штуку, которая будет ОЧЕНЬ быстро(относительно старта минимальной виртуалки/образа и чего другого) запускаться, быстро делает свою маленькую работу и выключается.
Из ключевых особенностей отмечу что функции должно быть в целом пофиг на своего состояние, она не знает изначально о предыдущем запуске и тп(те быть stateless). Все что нужно приходит в запросе.
Ври значит если у вас есть задача, которая удовлетворяет этим условиям, можно использовать этот удобный сервис и для масштабируемости, и для экономии и для кучи других фич.
Примеры:
ресайз изображений.
Генератор статистических сайтов(через админку производим обновление статистических файлов, это бывает не часто).
Чат боты
Разные спец информеры с определенной логикой.
И тд и тп, что хорошо ложится в определенную относительно простую функцию с простым входом данных(или без) и простым результатом работы.
В целом это решение не панацея, более того нужно четко понимать насколько выгодно/невыгодно переделывать на серверлесс платформы свою функцию, ведь мы точно жертвуем той же производительностью(помним что сервис не висит и не ждет нас постоянно, а пусть и очень быстро, но запускается), понижается прозрачность исполнения и усложняется отладка и прочее.
Но в любом случае, достаточно часто плюсы перебивают минусы, популярность у этого принципа есть. люди активно пользуются, так что много шишок уже набито, в целом зрелая штука.
А и да, насчет конкретного вашего вопроса.
PHP AWS Lambda нативно не поддерживает, все через костыли, впрочем с почти вменяемой производительностью.
И так как все таки AWS Lambda все же ближе к самому популярному нынче принципу serverless - функция как сервис, я не уверен что это правильная идея будет запускать атм Ларавел.
Те мы имеем минусы: отсутствие нативной поддержки PHP и такие заточенность под что-то простое, в итоге .. ну не знаю.
Я думаю плюшки serverless в виде нет мороки с настройкой сервера/облака можно решить многими другими сервисами. Впрочем может быть это будет не так выгодно в вашем случае, нужно исходить и рассчитывать по вашему сценарию работы вашего приложения. А потом решать, что лучше подходит.

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

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

Если вы при использовании фреймворка будете понимать как он работает, то это ничего страшного и даже хорошая практика. Тот же Laravel полный opensource, используешь какую либо часть, всегда можно начтаь изучать сам код непосредственно, читать документацию, блоги разработчиков, где и почему какие практики были использованы, а почему не были.
Короче говоря в любом случае все зависит от вас и вашего желания учится. Бери фреймфорк, строй сайт, видишь интересный инструмент, интересно как он работает можно идти в код посмотреть.
В большинстве ныне популярных фремфорках кодстайл на уровне, заодно и пркоачается этот навык.
Кстати, можешь попробовать начать подключать к своему проекты компоненты того же Symfony(он и в Laravel активно используется), и потихоньку заменять ими свои велосипеды, благо у Symfony все устроено так что почти все можно использоваться независимо друг от друга, чем пользуются множество крупных php проектов.