Nikita

laravel нежели на CMS- битрикс?

- как можно сравнивать продукт с фреймворком. Если взять любую доступную админку на Ларавел, то она даже близко не превзойдёт админку Битрикс.
Если уж сравнивать тогда ларавел с коммерческим фреймворком Битрикс. По техническим моментам фреймворк битрикса скорее всего уступает ларавел, но как это упрощает и решает задачи бизнеса?

прикрутить личный кабинет пользователя, с графиками + vue

- на самом деле Битрикс это коммерческий фреймворк, а админка это продукт на его основе. Если вы будете писать новый функционал, которого нет в продукте, что в Битриксе, что в ларавел вы будете это делать с нуля, писать и там и там на фреймворке.

1) Удобная система ( админ панель) с быстрой тех поддержкой

- это реальный большой плюс, который сокращает расходы на поддержку проекта.

2) Много функционала из коробки

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

3) Удобно интегрировать с CRM битрикс

- хороший плюс, который сокращает расходы на создание аналогичного функционала.

масштабировать проект очень сложно

- точно также как и в Ларавел пишутся модули и функционал.
Когда имеет смыл рассматривать преимущества Ларавел
- когда не типовой, индивидуальный интернет-магазин
- когда возможностей CMS Битрикс кардинально не хватает
- когда глубокая интеграция ТЗ в готовый функционал занимает больше времени, чем сборка аналога с нуля. И в итоге дороже. В этом случае бизнес считает деньги.
- гибкость для сложных проектов, но нужно эту гибкость представить в виде пункта коммерческого предложения, иначе это для бизнеса просто слово
- создание и полная кастомизация административной панели сайта под не типовые и сложные проекты
- скорость работы, для крупных интернет-магазинов это важно. Интернет-магазин получается реально шустрее тиражных решений.

Читем про CORS, узнаём, что что запросы с неидентичных портов блокируются, прописываем в конфиг CORS http://localhost:4200.

Слишком поверхностно задан вопрос. Если говорить об ОС WIndows - то там вся графика в системных библиотеках (dll, и т.д.) и графических файлах, которые загружаются по мере надобности.
Но сам процесс загрузки и то, что там делается в POST - это разные вещи, и они не пересекаются.
То есть, сначала идёт при включении считывание содержимого микросхемы биос (да, пропустим этап инициализации чипсета и самого процессора, это зависит от аппаратуры), и биос при выполнении уже проверяет и инициализирует основные части - MIS/SIO, чипсет, контроллер памяти, порты всякие, видеокарты и т.д. И если что не так, то либо остановится, либо проинформирует о неисправности и пойдёт выполнять следующие шаги. (например, если не найдена видеокарта, на большинстве биосов по умолчанию будет остановка с выдачей пост-кода ошибки, и далее не загрузится ничего; а если не найдена клавиатура, или SMART диска BAD - то поведение может быть и с остановкой, а может и продолжить выполнение, зависит от настроек). А уже когда этап выполнения POST завершится, то биос передаёт управление на первый сектор жёсткого диска, или на другое устройство, смотря как настроено. ОС уже никак не знает, что там до него делалось в процессе POST.
Другое дело - системы с EFI (UEFI). Там всё довольно тесно связано, и есть несколько фаз загрузки, но всё так же загрузка самой операционной системы будет после выполнения всех процедур в EFI. Разница только в том, что EFI более плотно связано с ОС, и сама ОС может хранить в чипе свои данные, и EFI может передавать данные и параметры в операционную систему.

Если нужно именно на этапе инициализации системы на базе EFI - то вполне можно собрать образ firmware, в котором сделать нужные анимации, и прочее. Но это выйдет слишком трудозатратно, и заметно замедлит загрузку. В линуксах и всяких бсд вон изначально при загрузке не экран с картинкой, а сообщения загрузчика, ядра ОС, и стартовых скриптов (системы инициализации). И не нужно никаких анимаций, всё по тексту понятно, что именно сейчас загружается и выполняется. В более современных системах сложнее - там уже systemd, параллельная загрузка и выполнение, и прочие плюшки. Плюсом обычно ставят как раз какую-нибудь анимацию вместо текстов, якобы она предотвращает появление сообщений консоли, которые замедляют процесс старта (на самом деле, это было давно и неправда). Например, plymouth. Эта заставка стартует практически с самого загрузчика, и вполне логично было бы её и сделать под это всё дело, если надо.
Остался у меня один вопрос - а ЗАЧЕМ? Ведь любые компы за последние лет 20 инициализировали железо (проходили POST) за доли секунды, и ещё от 1 до 3 секунд тратилось на загрузку всяких option ROM (сетевушки, рейд/ide контроллера, или ещё чего), и на раскрутку диска, чтобы с него загрузиться. О какой анимации речь? А сегодняшние компы, да с UEFI, да с SSD загружаются вместе с ОС за пару секунд! Сейчас никто и не заботится о том, чтобы что-то там в процессе загрузки Вам показать. Ладно, можно в автозагрузку запихнуть mplayer с видео любым, по вкусу. ОС уже конечно давно загрузилась, и ещё воспроизведение видео займёт 20-30 секунд. Да, красиво, да, можно понтануться перед друзьями (смори, как офигенно сделано, видно как комп загружается!). Но повторюсь, а кому это надо?

Нужно замокать rest сервис, чтобы он отвечал всегда заранее известным в тесте набором данных, и тестировать логику.

1, 2, 3) В документации ларавел, которую ты до сих пор не прочитал, написано, как правильно.

4) Можно вернуть null вместо массива. Кто запрещает?

Ещё стоит закопать стюардессу, перестав юзать curl и начать юзать guzzle/guzzle.

Deployment -> Excluded Paths

Тонкими лучше делать не только контроллеры, но и форм-реквесты. И любые другие классы. Для этого каждый должен выполнять свою функцию. Например, авторизацией в Ларавел занимаются политики авторизации. Кроме чистоты кода и отсутствия велосипедов, логику доступа в политиках можно юзакть по всему приложению. Типа $user->can('view', $post) и т.д.

пришла идея хранить в реквесте часто используемые переменные

Какую-то свою логику если хочется куда-то вынести из контроллера лучше использовать свои сервис классы, а не первые попавшиеся классы Ларавел.

пика? рили?
с подобной логикой: пик был достигнут лет 20–30 назад.

только всегда находились люди, с этим не согласные - и воплощали свои идеи: кто в коде, кто в железе.

Как настроите сервер. Можно требовать клиентский сертификат, можно требовать что бы соединение было только на определенной версии

Очень сложных проектов на Yii2 с открытым, да ещё и хорошим кодом очень мало)) Прежде всего, потому что Yii создан для быстрой разработки нарушая все правила сложных архитектур. А учитывая его устарелость, то тем более таких проектов мало. На форуме давно обсуждался этот вопрос. Там есть ссылки на проекты и код. Так же на сайте yiipowered.com есть список проектов, у некоторых с исходным кодом.

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

Если по теме, то начните изучать или искать DDD, CQRS, SOA, Микросервисы. В принципе это основные архитектурные подходы в разработке. На Yii по DDD есть хороший пример. Однако начинать НОВЫЙ проект на Yii2 используя даже самую сложную архитектуру - путь в никуда. Yii2 создан для других целей. Чтобы понять можно посмотреть ответ на вопрос: Актуален ли Yii2 Фреймворк в 2020?

Открываешь страничку модуля и читаешь:
firebase:

This SDK is intended for end-user client access from environments such as the Web, mobile Web (e.g. React Native, Ionic), Node.js desktop (e.g. Electron), or IoT devices running Node.js. If you are instead interested in using a Node.js SDK which grants you admin access from a privileged environment (like a server), you should use the Firebase Admin Node.js SDK.

firebase-admin:

The Firebase Admin Node.js SDK enables access to Firebase services from privileged environments (such as servers or cloud) in Node.js.

Короче: первое для клиента, второе для сервера.

Учись сам искать инфу, ты не сможешь вечно на каждый чих спрашивать тут.
(Нет, не сможешь. Точно не сможешь. Инфа 100%)