Олег

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

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

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

Теперь возмем CMS для сайта. Во фронт можно отписать шаблоны страниц, а сам движок в бакенд.

Ок. Сферический сайт PHP+MYSQL+JS+HTML+CSS
тут вроде просто. То что пишем на PHP+MYSQL бакенд. HTML+JS+CSS - фронт
И уточнять словом сервер нет необходимости. Работу можно поделить между верстальщиком и программистом.

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

Вернемся к приложениям.
"бакенд - сервер" означает, что приложение имеет серверную часть.
тут пригодиться еще один термин API - Aplitation Protocol Interface.

Технологий как с телефона/компьютера обратиться к серверу в интернете придумали достаточно много.
Простейшая из них очень похожа на общение с сайтом (GET/POST), только вместо HTML программам удобнее разбирать структуированные данные (json или xml)

Самое прикольное, что на каждом уровне цепочки общения что-то можно назвать фронтом и беком.
https://stackoverflow.com/questions/73778563/nginx...
Пример со стековерфлоу.
Nginx - общается с пользователями. Но вот человек вполне понятно для других спросил про фронт-сервер и бакенд. Откуда будут браться статические данные и куда передавать запросы требующие обработки.

Так, что "сервер" в названии это уточнение, что часть бизнес логики выполняется на другой машине (не текущей) или за нее отвечает другая программа

<?php
$mysecret = 'supersecret';

Минимальный совет из "PHP Правильный путь" звучит как храните свои конфиги хотя бы в виде php файлов.
Предположим, что мы сохранили такой скрипт в корне www.
При правильной настройке сервера посетитель увидит пустой экран по урлу //your.site/script.php
так как в нашем файле нет команд вывода.
В первой строке полный синтаксис, в варианте "<?" может случиться ситуация показа исходного текста, если сшорт таги отключены. И остается риск того, что php отвалиться и будет показываться исходный код.

Обще принятой практикой сейчас считается подход, когда все исходные файлы лежат выше диретории www рут.
В самой директории только один скрипт точки входа (index.php)

Ваши пароли скорее утекут по другой причине, чем из-за того, что к скрипту обратяться на прямую.

Вы используете eval c данными от пользователя или на сайте можно загружать через форму файлы.
На шаред хостинге ошиблись с разделением прав для ftp.

У Вас используются системы контроля версий кода и конфиги не добавлены в игнорируемые.

Чтобы избежать слива бюджета конкурентами, как-то надо учитывать уникальный показ для 1 IP адреса в сутки, за остальные показы этому же IP деньги списываться не будут.

Идеально для рекламодателя. За цену одного показа аудитория, сидящая за одним NAT сервером.

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

Прикиньте свою упущенную выгоду. Соотнесите с затратами на сделать подсчет лучше.
Если овчинка не стоит выделки, то и так сойдет.
Единственное рекламодателю показывал бы два числа. Всего показов (уникальных IP)

В этой статье вполне правильно написано
https://habr.com/ru/articles/803745/

То есть а зачем Вам именно этот "фулл" нужен ?
А потом уже можно подумать в каких комбинациях его набирать.

1. Очевидно, что если работа с сайтами То тут без HTML5+CSS3 и базового понимания JS никуда.
Собственно, а как это все рисуется в браузере у клиента.

2. Как общается броузер и сервер. Базовые знания об устройстве Internet. (4 уровня и прочее)
HTTP протокол и т.д.

3. "Рожден чтобы умирать"(Request-Router-Controler-Responce-Die) vs demon (постоянно в памяти).
То есть в каком стиле придется продумывать логику работы серверной части. Первая линейная (1-2-3). Вторая событийная
(Если есть А, то делаем первое. Если есть Б, то делаем второе)

4. Как хранить данные. СУБД и кей-валуе хралища.

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

А фулстек из HTML,CSS,JS,PHP,LAMP,NGINX,SPINX - это просто "веб-дев". Увы за сайты сейчас много не готовы платить.
Времена такие, что куча noCode решений, где за 3копейки можно получить готовый сайт

https://www.securedatarecovery.com/blog/macbook-re...
Гуи не отключаем. После всех шаманст все равно максимум будет так


https://support.apple.com/en-us/102603 - режимы загрузки

What does safe mode do?
Prevents certain software from loading as your Mac starts up. This includes login items and extensions that aren't required by macOS, and fonts that weren't installed by macOS.

Performs a basic check of your startup disk, similar to the more comprehensive check performed by the First Aid feature of Disk Utility.

Clears some system caches, including font caches and the kernel cache. These are automatically created again as needed.