Сегодня попробуем собрать микрофреймворк по описанным принципам. Будем делать так, чтобы минимизировать свой код. Поэтому, в отличие от полноценных микрофреймворков, у нас будет что-то ближе к начальному «каркасу». Я намеренно не хочу «улучшать» код и тем более раскидывать его по файлам, чтобы сохранить ясность в понимании того, как код будет работать.
В последующем вы можете сами его модернизировать так, чтобы вынести часть кода внутрь фреймворка.
Тема микрофреймворков достаточно актуальна, особенно на фоне сильно «разжиревших» полнофункциональных фреймворков. У каждого разработчика наверняка стояли задачи сделать быстрый и небольшой сайт, но ставить полноценную CMS или десятки мегабайт от популярного php-фреймворка, как-то душа не лежит. Хочется какой-то простой каркас на который можно было бы быстро «налепить» сво функционал.
Кажется, что таких «велосипедов» очень много. И будете правы, поскольку на PHP можно очень быстро написать любой web-каркас и поделиться с ним на Гитхабе. Но так было раньше, поскольку не было стандартов PSR, и все делали что хотели.
Когда появился PSR-7, то количество микрофреймворков резко сократилось и продолжает уменьшаться с выходом новых PSR. Если внимательно присмотреться, то в принципе останется только один фреймворк Slim 4, который поддерживает типовой набор PSR.
Решил опубликовать большой (!) лонгрид посвященный php-фреймворку Slim 4. Это микрофреймворк, а значит он содержит лишь самый минимум возможностей. С другой стороны Slim играет на поле full-stack фреймворков, таких как Symfony, Laravel и CodeIgniter.
Для работы с базой данных (любой), в PHP сейчас принято использовать PDO (PHP Data Objects). Раньше было так: в зависимости от используемой базы, нужно было использовать и её специфичные функции. Поскольку PHP поддерживает больше десятка баз, то появился и «зоопарк» функций: отдельно для MySQL, отдельно для SQLite, отдельно для dBase и т.д.
Но с точки зрения разработчика, работа с базой состоит из нескольких этапов:
То есть не важно какая база, схема работы всегда одна и та же. Таким образом и был создан PDO, который представляет собой единый интерфейс для работы с базами. Вначале рассмотрим «чистый» вариант работы с PDO, а потом как его упростить и сделать удобным с помощью библиотек Albireo Framework.
Сейчас вопросы безопасности полулярны и складывается впечатление, что разработчик просто обязан писать код с многочисленными проверками и защитами изначально. Но на самом деле так практически никто не делает — это достаточно сложно, поскольку на этапе разработки невероятно сложно учитывать все факторы. Разработчик в первую очередь должен решать основную поставленную задачу, а «обвеска безопасности» — это всё-таки вторичная задача.
В идеальном мире любой код должен тестироваться. Но в нашем суровом мире, код по факту тестируется уже конечным пользователем. Здесь очень важна реакция разработчика, который может оперативно исправить найденные проблемы.
Хорошая новость состоит в том, что в PHP уже есть несколько устоявшихся подходов, которые позволяют защититься от большинства уязвимостей.
Для отправки почты в PHP существует функция mail().
$to = 'user@site.com'; // кому $subject = 'Hello, user!'; // тема письма $message = 'How are you?'; // текст сообщения $headers = ''; // дополнительные заголовки mail($to, $subject, $message, $headers);
Сама по себе функция mail() ничего не отправляет, а лишь вызывает специальную программу (вроде sendmail, это указывается в php.ini), которой и передаёт входящие данные. А sendmail, в свою очередь уже и осуществляет физическую отправку письма.
За кажущейся простотой скрываются множество нюансов. Сложность в том, что обычное электронное письмо состоит из двух частей. Первая — это служебные заголовки, вторая — непосредственный текст сообщения. Исторически сложилось так, что мы не можем взять и просто отправить «голое» письмо, нужно ещё указать дополнительные заголовки. Если этого не сделать, то адресат не сможет его получить, поскольку почтовый сервер скорее всего заблокирует, посчитав спамом.
По идее про «API» должны знать все разработчики. Переводится как программный интерфейс приложения, но поскольку для нас наибольший интерес представляет Интернет, то речь пойдёт о Web API. Под ним обычно понимают некие http-запросы между клиентом и сервером. То есть всегда есть тот, кто отправляет запрос и есть тот, кто его обрабатывает и возвращает результат.
Простой пример. Вася — верстальщик, который делает сайт и знает только HTML и JavaScript. На сайте есть страница, которая выводит список пользователей. Чтобы его отобразить, нужно вначале откуда-то получить данные.
Петя, наоборот, ничего не знает о JS и верстке, но неплохо разбирается в PHP и базах данных. То есть Петя делает так, чтобы можно было сформировать данные о юзерах, а Вася сможет их получить через простой Ajax-запрос к серверу. Петя даёт Васе URL-адрес такого запроса, http-метод и список возможных параметров. Вася указывает их в fetch() или XMLHttpRequest() и получает готовые JSON-данные, которые прекрасно работают с его js-скриптами.
Вот этот механизм, когда программа предоставляет интерфейс для управления и называется API.