15.10.2020 22:20:39 |
Автор: Не Wordpress-ом единым
Рынок CMS длительное время оставался местом, где Wordpress, Joomla, Drupal тройка абсолютных лидеров. Эти прекрасные времена уже постепенно проходят, хотя WP, сбавляя в динамике появления новых сайтов, все ещё сохраняет лидерство. Не мудрено: активное сообщество, огромное количество плагинов. Но, эта статья вовсе не будет посвящена восходящим звёздам рынка систем управления контентом (привет, решениям на базе Laravel). Скорее даже, объектом нашего внимания будет черная материя, которая находится несколько в стороне. А именно барабанная дробь
Статические сайты
Кому нужна статика в 2k20?
Рациональный вопрос! Казалось бы, времена телефонного интернета и Windows95 уже прошли, но спрос на статическую генерацию html кода вновь начинает набирать обороты. И всему виной корпорация добра, разумеется. Google PageSpeed тот самый великий и могучий Урфи В общем, именно этот измеритель производительности веб-страниц стал и двигателем прогресса мирового интернета, и головной болью всех веб-разработчиков, а уж тем более фрилансеров. Результаты измерений сего инструмента базируются на стандартах Google, а далече известно, что онные положено в основу ранжирования. Да и объективно, загрузка страницы более трёх секунд увеличивает количество отказов автоматически. Таким образом, статика становится одним из альтернативных решений на смену или в дополнение к динамической сборке страниц силой любой CMS, фреймворка либо самописных вариантов.
Хьюстон, у нас проблемы или мой случай
По долгу службы я занимаюсь обслуживанием множества проектов, среди которых есть парсеры, но и также решения в сфере e-commerce. На жизнь не жалуюсь, но возникла задачка не из разряда 2 класс, начальная школа. Я, как разработчик, и менеджер (а управление своим маленьким делом, как известно, требует навыков и из этой сферы), как это на польском dostaem si do martwego kta (попал в глухой угол, одним словом). Условие следующее: нужно написать в течение нескольких дней решение, которое должно просто устанавливаться и обслуживать любое количество статических страниц. Более того, администратор должен иметь возможность быстро удалять и добавлять такое решение на любой проект через FTP/SFTP соединение или даже если у него нет доступа к FTP/SFTP. С другой же стороны условием было то, что минимальная версия это PHP 5.6 и она должна поддерживаться также прекрасно, как и каждый более современный вариант.
Администратор должен
- удалять/добавлять/изменять страницы при помощи админки;
- глобально и быстро искать в контенте страниц (учитывая разные кодировки, языки;
- искать по названиям файлов;
- удалять/вставлять/изменять на всех страницах нужные элементы одним кликом из админки;
- решение должно быть простым как в установке, так и в удалении.
Cекьюрность не должна позволять использовать SQL инъекции либо какие-либо другие попытки вмешательства в работу.
Дополнительным обязательством была бы возможность использовать админ панель и все ее функции через API. Грубо говоря, при наличии таких админок на 50+ доменах, должен быть доступ к ним удалённо путем возможности делать запросы.
Чехия, вечер, лето, кофе
Крайне спокойные вечера в Крконошах только способствуют лени. Но, как говорит старая пословица, кто не работает
Таким образом, собравшись с мыслями и воспряв духом да и решительностью, я принялся проектировать. Вещь предельно ясная, что создание процедурного решения не может быть чем-то максимально успешным в данном случае. Не секрет, что есть перспектива поддерживать систему и в будущем, при этом менять все не слишком хочется.
И да, чёрт возьми, я решил перенести в один файл уже устоявшийся подход в большинстве фреймворков ООП и MVC концепцию.
С точки зрения быстродействия процедурщина, быть может, была бы наиболее лучшим вариантом, но:
- не забудем об аспекте роста потребностей клиента и параллельной надобности добавлять новые возможности к интерфейсам нашего веб-приложения;
- проблемы с ментальным состоянием программиста хоть я и был согласен мириться с тем, что всё будущее этого проекта будет возложено исключительно на мои могучие плечи, но вряд ли я бы морально перенёс бесконечное усложнение процедурного решения и отсутствие внятной бизнес логики;
- потребность возможной публикации проекта для всенародных масс такая надобность к моменту публикации сего опуса становится актуальной, поэтому лучше когда руки развязаны и будущую документацию можно оснастить вполне понятными даже не функциями, а структурами объектно-ориентированного мышления и разделения зон ответственности приложения на ярко выраженный фронт-энд, бэк-энд.
От баз было принято решение пока что отказаться по причине отсутствия какой-либо надобности, поэтому термин модель во всём, что выше это нереализованная концепция в моей архитектуре. Нереализованность здесь услужила хорошую службу, ведь SQL инъекция перестаёт быть возможна в принципе.
Структурирование
Исходя из того, что у нас один файл и есть главное правило добавляться должен только один файл и после сразу можно работать и обслуживать директорию, в которую добавили, ясное дело, что даже классы не спасут от чёрт ногу сломит.
Каково же решение?
Интуитивно: файл разбиваем на структурные части вида: базовые системные классы в самом верху, контроллеры пониже, виды еще ниже, но и весь балет закрывают роуты. Каждая часть получила шапку из комментов с объяснением, дабы через время не забыть что здесь:
/** This is the part for routing*Additional information...*/
Нейминг согласно функциональному предназначению методы классов получили имена согласно camelCase практике и соответствуют функциональной роли, к примеру checkAdminCredentials это более чем понятная формулировка для метода.
Попытка описать всё что можно не скажу, что соответствовал этому намерению до самого конца разработки, в конце концов, я лавировал между быстротой и читабельностью кода, но ключевые решения мне удалось сопроводить комментариями вида //to get static html.
Как сделан роутинг?
Надобность более-менее понятного разделения интерфейсов была мною сразу же принята в качестве ключевой потребности. Этот компонент, если не должным образом реализовать, может стать точкой пика роста приложения из-за запутанности в том, какой роут какой контроллер вызывает.
Исходя из упомянутой выше проблемы, я сделал класс для роутинга достаточно примитивным, но функциональным. Роутинг работает при помощи GET запросов конечно, не совсем эстетично, но сиюминутную потребность в быстрой реализации решает на 100%. Роутер стал единственной точкой входа для веб-приложения, что, как по мне, идеальное решение для простоты разработки. В этом классе происходит сборка фронт-энда и бэк-энда апликации и вывод return-ом сформированного HTML.
Вопрос: написал ли я велосипед?
Я склонен к подозрению, что подобные решения уже написаны в прошлом, но на момент июля 2020 ни английский, ни польский, ни чешский, ни русский с украинским не помогли мне найти что-то стоящее и применительное к моему случаю. Поэтому во мне включился создатель, и я от всей души проектировал решение актуальных задач бизнеса. Ведь, если есть проблема её нужно решить максимально быстро и экономно, да ещё и про качество не позабыть.
Наглядный пример производительности
Одна крайне известная CMS, имя которой не принято называть:
Моё решение:
Очевидно, что скорость получения первого байта также выше, как и все прочие показатели, связанные со скоростью загрузки, даже не буду демонстрировать количество запросов на front-end в классических CMS и в этом мини-решении.
Будет ли продолжение?
Сейчас система в большей степени написана и успела увидеть несколько обновлений. В ближайшее время я планирую подготовить документацию и в том либо ином виде, но выпустить это решение в открытое плаванье, хотя, нужно сказать, что задачи внутренние решает каждый день великолепно. Есть ещё несколько интересных и занимательных моментов из раздела файлового поиска и поиска контента в html файлах, которые удалось реализовать в обход возможностей PHP, что сделало выполнение этих запросов существенно быстрее. Об этих темах обещаюсь написать в ближайшее время.
Категории: 
