Метка: php

  • Фуллстек парадокс

    Фуллстек парадокс

    В начале 2000-х в веб-разработке не было фронтэндов или бэкэндов.
    Была профессия вебмастер. Этот человек мог сделать сайт целиком. Он умел общаться с полиграфическим дизайнером про внешний вид сайта, верстать HTML таблицами, оптимизировать графику, писать java script. Стек был небольшой и было мало слоёв абстракции.
    Если было нужно что-то покруче, звали программиста и он писал CGI-скрипты на Perl, PHP или C.

    Прошло 25 лет. В этом году искал для клиента fullstack-разработчика. Вакансии такие на рынке есть. Например, одновременно с моей вакансией продвигали объявление от Теремка на такой же стек. На такую вакансию массово откликаются фронтэнд-разработчики. Почему так?

    В момент, когда фронт научился писать запросы к базе данных и создавать API-методы, он достиг своей полноты. В его мировоззрении всё жизненное пространство в этот момент освоено. Всё так, но для бэкэнд разработчика уровень фронтов на его территории — Intern или Junior.

    Современный бэкенд разработчик часто знает HTML, CSS и Java Script. Может так случиться, что был у него опыт разработки на React, но он не будет считать это значительным достижением. Хорошо, если в резюме укажет. Его территория упирается с одной стороны в серверное администрирование и облака, с другой находится уровень железа: производительность процессора, работа с памятью, операции чтения и записи на жесткий диск. Пляж фронтэндов находится на периферии его владений и занимает небольшой участок с выходом в море.

    Зрелый бэкенд разработчик может в море не плавает, но может залезть в код на фронте, сделать необходимое “чтобы работало” и пойти делать свои дела. Вряд ли он уделает фронта на его территории, но у него есть ощущения “тут всё понятно”.

    Количество абстракций в процессе разработки выросло. У пирога было три слоя, а в современном рецепте их пятнадцать. Изобретают новые фреймворки, меняются библиотеки и подходы. Рынок делает веб-программирование всё более абстрактным и сложным.

    Практические выводы:
    – Если вам нужен в команду разработчик с полным спектром знаний — ищите сеньора бэкендера, у которого был опыт работы на фронте. Вакансии Веб-разработчик, Программист или Backend-developer. Но делать фронт его руками очень дорого.
    – В команду нужно брать и фронтов и бэков. Бэки будут ворчать и не хотеть делать задачи фронтов, фронты не владеют всей картиной происходящего на бэке.
    – LLM уже сейчас помогает бэкендерам делать сносный фронтэнд. Скоро всё перемешается снова.

  • Попробовал модный веб-сервер Caddy вместо Nginx

    Попробовал модный веб-сервер Caddy вместо Nginx

    Попробовал модный веб-сервер Caddy вместо Nginx.

    Обычно в архитектуре проектов я использую голый NGINX. Мой блог вряд ли в первое время столкнётся с высокими нагрузками, поэтому можно поэкспериментировать.

    NGINX (Engine X) — самый популярный веб-сервер (33% рынка), написанный на C. Изначально был написан 20 лет назад программистом из Rambler.
    Раньше Nginx многие использовали как обратный прокси для Apache2, чтобы его ускорить. Nginx занимался статичными файлами (картинки, CSS), а Apache2 запускал PHP-скрипты. Постепенно Apache2 стали убирать и всю работу переносить на Nginx, потому что он быстрее и лучше держит большие нагрузки. Есть большая экосистема дополнений, отличная документация и множество примеров использования. Стабильный продукт, с которым я работаю на всех проектах.

    А тут в инфополе стал мелькать Caddy. Чем же он покоряет разработчиков?
    – Более лёгкая конфигурация SSL-сертификатов. Точнее, её нет, Caddy делает всё сам — пользователю больше не нужно настраивать стандартные сертификаты Let’s Encrypt.
    – Поддержка HTTP/2 и HTTP/3 из коробки.
    – Поддержка компрессии gzip и zstd из коробки.
    – Простой синтаксис конфигурационных файлов. Очень похож на Nginx, но проще и яснее. Конфиги сокращаются в размере, вероятность ошибки ниже.
    – Caddy — это всего один исполняемый файл без зависимостей. Его легко устанавливать и обновлять.
    – Новый плагин можно подключить к Caddy без перезагрузки и простоя в работе.
    – После установки Caddy показал симпатичную страницу по-умолчанию с небольшой инструкцией.

    Есть у него и минус:
    – Caddy на предельной нагрузке может обработать меньше запросов, чем Nginx. Приоритет Caddy на простоте использования и автоматизации. На этом бенчмарке разница начинается от 10 тысяч запросов в секунду, что практически недостижимо для маленьких проектов.

    Мои впечатления — мне понравилось с ним работать. Действительно легкая установка и конфигурация. Видно, что авторы много работали с другими веб-серверами и свой продукт сделали удобным и современным.

    На моём сайте пока что висит статическая заглушка, вот весь конфиг:

    fullstackfounder.ru {  
           root * /var/www/fullstackfounder.ru/public  
           file_server  
           encode zstd gzip  
    }  
      
    www.fullstackfounder.ru {  
           redir https://fullstackfounder.ru{uri} permanent  
    }

    Аналогичный конфиг у Nginx выглядел бы вот так:

    server {
        listen 80;
        server_name fullstackfounder.ru www.fullstackfounder.ru;
    
        # Redirect all HTTP to HTTPS
        return 301 https://$host$request_uri;
    }
    
    server {
        listen 443 ssl http2;
        server_name fullstackfounder.ru;
    
        ssl_certificate     /etc/letsencrypt/live/fullstackfounder.ru/fullchain.pem;
        ssl_certificate_key /etc/letsencrypt/live/fullstackfounder.ru/privkey.pem;
        include             /etc/letsencrypt/options-ssl-nginx.conf;
        ssl_dhparam         /etc/letsencrypt/ssl-dhparams.pem;
    
        root /var/www/fullstackfounder.ru/public;
        index index.html index.htm;
    
        # Enable gzip
        gzip on;
        gzip_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;
    
        # Canonical redirect: www → non-www
        if ($host = 'www.fullstackfounder.ru') {
            return 301 https://fullstackfounder.ru$request_uri;
        }
    
        location / {
            try_files $uri $uri/ =404;
        }
    }

    Очевидно, что при работе с Caddy будет проще всё настроить. Мой вывод: дружелюбный сервер для разработки, DevOps, небольших проектов и соло-разработчиков. Сомневаюсь, что он завоюет высокие нагрузки, но свой вклад в улучшение веб-серверов он уже внёс.

    Буду запускать на нём WordPress, посмотрим, что из этого выйдет.

  • Почему я выбираю VDS?

    Почему я выбираю VDS?

    Логично для блога выбрать минимальный тариф на обычном дешёвом хостинге — на так называемом Shared. На таких тарифах на одном сервере размещены сотни клиентских сайтов. Админ хостинга уже настроил все службы и программы, чтобы обычный пользователь мог про это не думать.
    Но я для блога беру минимальный виртуальный сервер примерно за те же деньги. Для меня это полная свобода действий.

    Вот что я смогу сделать на VDS и не смогу на обычном хостинге:
    – Разместить на одном сервере сколько угодно сайтов и привязать к ним любое количество доменов.
    – Динамически менять ресурсы на сервере.
    – Не переживать, что мой сайт перенесли на другой сервер, поэтому нужно поменять IP-адрес в DNS. На шаред хостингах это могут делать несколько раз в год, нужно следить за уведомлениями, чтобы сайт не перестал работать.
    – Настроить сервер под меня с помощью пары ansible-скриптов.
    – Поставить нужный мне веб-сервер Caddy или кастомную сборку NGINX. Избежать Apache2, который до сих пор часто работает на шаред хостингах.
    – Разместить публичную папку сайта в любой папке, а не только в предварительно за меня выбранной public_html. Для моей сборки WP или Laravel это важно.
    – Установить git, composer, WP-CLI нужных мне версий и обновлять их самому.
    – Поставить любую версию PHP с нужными расширениями и оптимизировать все настройки, включая OpCache.
    – Настроить все параметры для базы данных MySQL.
    – Добавить сборщики для фронта (npm, pnpm).
    – Добавить memcached для кэширования в оперативной памяти — пригодится для ускорения WordPress.
    – Управлять логами, менять их формат, включать дополнительные логи для медленных скриптов и запросов. Размещать логи в нужной мне папке.
    – Поставить CI-агента от GitLab, который будет автоматически обновлять сайты после внесения изменений в Git.
    – Отключить FTP-протокол, чтобы сайт не взломали через утечку FTP-паролей.

    Создал VDS у Beget за 290 рублей в месяц.
    Конфигурация: CPU 1 core, 2 GB RAM, 10 GB NVMe, Ubuntu 24.04.

    Посты по теме:
    – План запуска блога
    – Удобный SSH-доступ
    – Выбор хостинга для сайта

  • Безопасность веб-сервера

    Безопасность веб-сервера

    Безопасность сайта начинается с уменьшения площади возможной атаки.

    Чеклист, который выработал и применяю у себя:
    – IP-адрес реального сервера никогда не был прописан в DNS домена. В DNS попадает proxy или балансер — от Cloudflare, Fortes, Qrator или вашего другого сервера.
    – Отключена возможность зайти под root пользователем. Вначале сделали нового пользователя, дали ему sudo-права, потом запретили вход из-под root.
    – SSH-логин возможен только по ключу, пароли отключены совсем.
    – SSH работает на нестандартном порте — 22-й слишком очевиден, меняем.
    – Стоит и настроен firewall. Закрыты все порты, кроме нужных: 80 и 443 для сайта, порт для SSH, порт под метрики для мониторинга. Мой выбор ufw, его вполне хватает всё перекрыть.
    – Установлен fail2ban — чтобы не донимали сервер брутфорсом.
    – Операционная система и системные программы периодически обновляются.
    – На сервере отключена возможность отправки почты. Совсем. Если взломают — сервер не станет рассадником спама и не нужно будет его IP вычищать из блеклистов. Вся почта отправляется через внешний SMTP.
    – Не ставим или удаляем FTP — протокол устаревший и через него часто ломают серверы.
    – Во всех папках для загрузки файлов через сайт стоит запрет на выполнение кода. В nginx и apache прописывается запрет. WordPress и Битрикс чаще всего ломают именно так — заливают исполняемый PHP-файл в загрузки и запускают по прямой ссылке.
    – PHP позволяет запретить вызов некоторых функций. Вам точно нужен eval()?
    – В идеале — код движка размещён выше корня веб-сервера. Так сделано во всех “взрослых” фреймворках. WP и Битрикс требуют ухищрений, но тоже можно кое-что сделать.
    – Движок обновлён до свежей версии. Тут у клиентов зачастую беда, потому что поддержкой не занимаются.
    – Код сайта в git. Всегда можно посмотреть и откатить любые заражения за одну минуту. git reset --hard и всё почистили.
    – Минимум раз в сутки делается бэкап базы данных и загруженных файлов.
    – На сервере установлены и периодически запускаются руткит-сканеры.

    Это базовые действия. Опытные сисадмины добавят ещё пару десятков пунктов.
    У меня большая часть этих действий происходит автоматически, потому что прописана в ansible-плейбуке. Но и руками делается тоже быстро.

    А что я забыл и вы бы добавили в этот чеклист?

  • Почему WordPress — это хорошо

    Почему WordPress — это хорошо

    Почему WordPress — это хорошо.

    Идут баталии React vs Vue, у новичков стоит вопрос выбора Python/TypeScript/PHP/Rust/Go.

    В это же время из 200 миллионов активных сайтов 43% работают на WordPress. Нет более популярной CMS.

    На WordPress работают сайты NASA, New York Times, Techcrunch и каждый второй сайт, который вы открываете.

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

    Самые частые жалобы:
    – Медленный? Посмотрите на лидеров рынка с огромной посещаемостью и настройте кэширование.
    – Взламывают? Надо было приложить небольшие усилия, настроить сервер и обновить плагины.
    – Неудобный? Большая часть удобства состоит из привычки, а не из “интуитивности”.

    WordPress действительно несколько опоздал на фестиваль современных технологий. Но догоняет всеми силами.
    Под капотом вы найдёте привычные и любимые разработчиками инструменты. React и REST API — из коробки. Консольную утилиту WP-CLI. Поддержку продвинутого кэширования с помощью Redis, memcached и php-op.
    Пара шагов чуть глубже и появится возможность использовать git, composer, s3, CI/CD, пре-процессоры и сборщики JS/CSS. А как насчёт использования blade-шаблонизатора от Laravel и классов Symfony?

    Старичок живой, весёлый и развивается, несмотря на скандалы, брюзжание и выход из моды.

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

    Если ваш сайт можно сделать с помощью WordPress — скорее всего, это будет оптимальным выбором.