Robur

Сделайте игру - симулятор менеджера автовокзала. С забастовками, непредсказуемыми ценами на соляру, таксистами которые ловят клиентов у входа и переманивают, проблемами со сломанными унитазами в туалете и прочим.
Если будут какие-то вопросы - прмо скажите "как задание дали так и понял".

видимо этот конкретный сервер get обрабатывает быстрее чем post, почему- кто ж знает.
Вообще get и post это два совершенно несвязанных запроса, даже по одному урлу и они могут делать абсолютно разные вещи.

Какую опасность представляет GET запрос, если в ссылке есть важные данные?

ссылки могут сохраняться во всевозможных логах и кешах, в случае с post данные обычно передаются в теле запроса и чаще всего никуда не сохраняется, в случае с get вероятность больше.
Надо понимать что если вы с post что-то передаете в ссылке - то проблемы все те же самые что с get.
Если хотите важные данные передавать, то post+https.

разделяете в голове одно от другого отдельно статика (html/js/ картинки, вот это все что лежит просто в файлах в том же виде в котором их получит клиент), отдельно HTTP api.
Дальше ответы на большинство ваших вопросов приходят сами. в целом - как угодно, в зависимости от ваших условий, желаний и предпочтений.

Можно статику отдавать по одному имени, а апи по другому. app.mydomain.com и api.mydomain.com
или и то и другое по одному имени, но для апи будет отдельный путь /api например или и для апи и для статики будут разные пути mydomain.com/app и mydomain.com/api
или на разные порты
Можно разделение сделать на nginx/apache. А можно на уровне вашего бекенда.
А можно статику вообще положить в облако и пусть они там думают про все. А бекенд положить в какие-нибудь контейнеры. Или вообще на serverless технологиях и вообще не знать где этот ваш код запускается и как к нему запросы идут, достаточно знать только урл.

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

Но самый обычный способ - статика на один урл, апишка на другой.

без описания задачи, ограничивающих условий, проблем которые перед вами стоят, того что вы понимаете под iis тонкого и толстого клиента и еще пачки деталей ваша схема и вопрос несколько бессмысленны.
Ответ на вопрос заданный в таком виде: да хрен его знает.

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

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

Тру гаражные стартаперы собирают их вообще без программистов, на гуглодоках, запперах и прочем. :)
некоторые даже поддерживают тренд сервисами типа https://www.makerpad.co/

Потому что оно там есть.
Бонус - совет: Смотрите вкладку networks в девтулзах

Мы то тут откуда это знаем?
Оценка того стоит это делать или нет и принятие решение по переносу - это ваша ответственность.

Если вы понятия не имеете что лучше, и не можете решить, попробуйте так:
Пишете в столбик
1. все проблемы которые есть сейчас на старом хостинге у клиента
2. все проблемы которые на этом хостинге будут с вашим новым сайтом у клиента
3. все проблемы которые на этом хостинге будут с вашим новым сайтом у вас
4. что из этого решит переезд на новый хостинг
5. проблемы которые будут у вас и у клиента на новом хостинге.

вычеркиваете одно из другого, что перевесит - то и делаете.

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

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

Использовать браузерное Api. И вы же надеюсь понимаете что без согласия пользователя это не сделать?

С чего начать - посмотрите какая система стоит в качестве решения доступа к wifi в вашем отеле. Все что вам нужно это чтобы после логина она перенаправляла пользователя на ваш сайт.
Дальше - вам нужен ваш сайт - делаете его абсолютно так же как и любой сайт в интернете ( и там же где-то в интернете его и размещаете). Если хочется - ограничиваете доступ только для посетителей отеля, например по IP.
Гуглите не "внутренний сайт для отеля" а "как сделать свой сайт". Дальше - по обстоятельствам тема несколько большая :)

Стоит ли - совершенно отдельный вопрос и никто вам без какого-то исследования на эту тему ничего внятного не ответит.

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

Главное что вам в 16 уже можно легально работать. Вас не спрашивают не потому что думают что вам 30 а вы скрываете. А потому что людям все равно. Так что работайте и все. Кому важно - спросят, тогда и ответите и там уже разберетесь как быть дальше, по реакции.

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

Насколько я знаю, сам HTTP никак это не регламентирует, так что остается на осмотрение клиента.
WebKit скорее всего ждет до таймаута, потом завершает соединение.
NodeJS - могут быть разные клиенты/библиотеки и вести себя тоже по разному, но с большой вероятностью по умолчанию делают то же самое

А в чем именно проблема? Показали пост в фиде - добавляйте просмотр. Чтобы было более близко к реальности - добавляйте только когда он на экране пробудет хотя бы секунд 5.