Когда нужен backend...?

Question

Вот есть простой сайт , всего 3 страницы, верстка прям на чистом html, css, немного (совсем чуть-чуть) js, упор сделан на визуал, на дизайн и картинку, так сказать. Как этот сайт разместить в интернете? Можно ли его захостить на каком то сервере, на котором установлен веб-сервер Apache или Nginx который будут отдавать эти статические ресурсы по запросам /index.html /about.html Не нужно же для этого устанавливать на этом сервере какой то фреймворк по типу Django и писать на нем обработчики этих маршрутов, правильно? По идее, я как бы догадываюсь, что можно самому купить старенький комп, поставить на нем Ubuntu, Nginx, положить эти файлы, и все, готовый сервер в работе?

Answer 1

Такой сайт можно разместить даже через GitHub Pages, абсолютно бесплатно, если конечно вам не принципиально использовать для него свой собственный домен. Впрочем, подозреваю, что даже собственный домен можно будет использовать с помощью CNAME-записей, правда, не знаю, как к такому относится GitHub. Backend для такого сайта, если он полностью статический, не нужен.

Дополнение

Свой собственный домен действительно можно, по этому поводу есть даже отдельная статья: "Настройка личного домена для сайта GitHub Pages".

Собственно про backend

Backend нужен для получения динамического содержимого с сервера. Чаще всего в данном случае, помимо самого backend'а, в генерации динамического контента задействована также какая-то база данных.

Изначально nginx разрабатывался Игорем Сысоевым исключительно как веб-сервер для отдачи статики и обратный прокси-сервер для обслуживания всех остальных запросов, к статике не относящихся. В начале 2010-х годов, когда львиная доля backend'ов была написана на PHP, очень популярна была связка nginx + Apache, nginx для статики и Apache для PHP (и всего остального). Это уже потом довели до ума PHP-FPM, а nginx научился помимо HTTP в FastCGI и другие протоколы. Никакой магии в выборе способа обработки запроса у nginx нет, в подавляющем большинстве случаев он выбирается в зависимости от префикса URI запроса (в некоторых случаях, например, для сайтов, написанных на PHP - в зависимости от суффикса). Вот несколько примеров упрощённых конфигураций nginx для понимания.

Статика + API на node.js, запросы к API начинаются с префикса /api/:

server {
    server_name example.com;
    # Статика (для всех запросов, кроме запросов к API)
    location / {
       root /var/www/html;
    }
    # Так называемый "префиксный" location для запросов к API
    # Для обслуживания запроса выбирается location с наиболее
    # длинным префиксом, совпавшим с префиксом URI запроса
    location /api/ {
        proxy_pass http://127.0.0.1:3000;
    }
}

Django через uWSGI, с обслуживанием запросов к статическим файлам с помощью nginx, запросы к статическим файлам начинаются с префиксов /static или /media/:

server {
    server_name example.com;
    root /var/www/project;
    # Для запросов к статическим файлам
    location /static/ {}
    location /media/ {}
    # Для всех остальных запросов
    location / {
        include uwsgi_params;
        uwsgi_pass unix:/run/wsgi.sock;
    }
}

Сайт на PHP:

server {
    server_name example.com;
    root /var/www/site;
    index index.php;
    # Запросы ко всем статическим файлам...
    location / {
        # Последний параметр директивы try_files - так называемый fallback URI
        # Всё, что не соответствует имени физического файла или директории
        # (относительно корневого каталога), уходит на обработку в index.php
        try_files $uri $uri/ /index.php?$args;
    }
    # ...кроме PHP скриптов, так как location, определённый с помощью
    # регулярного выражения, имеет больший приоритет при выборе способа
    # обслуживания запроса, чем обычный префиксный location
    location ~ \.php$ {
        include fastcgi_params;
        fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
        fastcgi_pass unix:/run/php-fpm/www.sock;
    }
}

БЛОГ НА HUSL

Когда нужен backend...?

Ответы (1 шт):