«Плавающий интерфейс», или как упорядочить разработку frontend + backend

Без лишних дифирамбов перейдем к сути.

Каждый из тех, кто когда либо в своей жизни делал сайт сложнее домашней странички своего кота, знает не понаслышке о проблеме передачи требований от фронтенд разработчиков к бекенд программистам. Много было пролито крови и сорвано сроков из-за этого. Вспомните, как было хорошо раньше, когда один человек мог сверстать простенький 3х колоночный шаблон и запрограммировать серверную часть.

О времена, О нравы. © Цицерон

Но сейчас совершенно другое время, и совершенно другие требования. Соответственно на проект приходится подключать несколько фронтенд и бекенд разработчиков. Как обычно выглядит шаблон ленты новостей, пока самого механизма новостей, или способа взаимодействия с ним нет:
<?
$news_list = array(
	array('id'=>1,'title'=>'news 1','text'=>'text'),
	array('id'=>2,'title'=>'news 2','text'=>'text'),
	array('id'=>3,'title'=>'news 3','text'=>'text'),
	// ...
);
?>
<ul class="news">
<?foreach($news_lsit as $news){ /* выводим тело анонса */ }?>
</ul>

Плюсы:
  • быстро;
  • ...
Очевидные минусы:
  • фронтендщику придется тратить время на постановку задачи\написание мануала\дерганье бекендщика;
  • нет единого механизма передачи данных (фронтендщик может запросить данные через ajax, или отрендерить их непосредственно в шаблоне);
  • после реализации функционала нужно очищать шаблон от мусора.

Идея

Намучавшись от этой вечной чехарды, в недрах нашей компании был изобретён принцип «плавающий интерфейс». Проблема заключается в том, что бы связать работу фронтенд и бекенд разработчиков в одной точке, в одном сервисе. Для этого было предложено написать бекенд разработчиком один класс (точку входа), который будет использовать фронтенд разработчик в шаблонах. А когда фронтендщику потребуется новый функционал, он напишет расширение (extends) с методом заглушкой. Которая в последствии перейдет в функционал основного класса, а из расширения будет удалена. Что-то вроде этого:
  • /app/views/шаблоны
  • /app/ext/Frontend.class.php
  • /app/ext/FrontendExtended.class.php

// /app/ext/Frontend.class.php
// функционал, который уже реализован
Class Frontend{
	public function getNewsList($limit=10){ /* реализация */ }
	public function getNewsByID($news_id){ /* реализация */ }
	public function getRelatedNewsList($news_id, $limit=4){ /* реализация */ }
}

// /app/ext/FrontendExtended.class.php
// функционал, который необходимо реализовать
Class FrontendExtended extend Frontend{
	public function getNewsByCode($news_code)
	{
		return array('id'=>33,'title'=>'news 33','text'=>'text');
	}
}

// где-то в недрах системы шорткат вызова
// класс может быть и синглтоном, если у него будут свойства-состояния
function F(){
	return new FrontendExtended();
}

Благодаря этому подходу, теперь фронтендщик может использовать уже «почти» готовую реализацию апи (вместо заглушки, что была раньше). То есть что-то вроде того:
<div class="news">
<?
// мы знаем, что так передавать параметры нельзя, это всего лишь пример
$news = F()->getNewsByCode($_GET['code']);
/* выводим тело новости */
?>
</div>

Осталось только бекенд разработчику заглянуть в файл /app/ext/FrontendExtended.class.php и реализовать методы, которые там описаны в основном файле — /app/ext/Frontend.class.php

Не сервером едины.

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

Итоги.

Итак, благодаря такому подходу, видятся сразу несколько плюсов:
  • есть одна единственная точка взаимодействия фронтенда и бекенда;
  • легко расширять новым функционалом;
  • легко покрывать тестами;
  • легко передать весь функционал куда угодно (ajax json, функция шаблонизатора, напрямую из кода шаблона);
  • сокращается время передачи требований бекенд разработчику;
  • ИМХО нагляднее и понятнее чем просто переданные в шаблон параметры.

Минусы:
  • Фронтендщик должен знать хотя бы минимально серверный язык;
  • ...?

Призываю сообщество обсудить эту идею. Критика приветствуется, это всего лишь концепт. И да, если такая практика уже существует, хотелось бы почитать что-нибудь по этому поводу.

С уважением, Роман.

10 комментариев

avatar
Ещё раз наступлю на старую мозоль. Этот поход избавит от мелких скриптов в папке ajax.
avatar
Годная практика! Всем советую!
avatar
Идея очень здравая, действительно может cэкономить массу времени.
В минусы поставил бы скорее не то, что фронтендер должен знать серверный язык, а то, что он должен понимать архитектуру проекта и следовать принципам, заложенным серверными программистами. В противном случае, если специалист по фронтенду пришел извне или просто новичок, он насоздает методов, реализовать которые серверные программисты будут не в силах или не захотят. Например, getCatsPhoto($filter = 'funny') или getUserPassword($noHashAndSalt = true).
В случае, когда над проектом работает сплоченная команда, таких проблем конечно не возникнет и идея должна сработать:)
avatar
Для таких случаем можно оставить метод фронтендщика в FrontendExtended как обертку, а во Frontend сделать адекватный интерфейс.
avatar
Сомнительно как-то это все выглядит. Класс раздуется до неимоверных размеров.
avatar
Тут поможет декомпозиция класса в chain стиле. В итоге получится например вот так:
<?
$news_list = F()->news()->get()->allByCategory($_GET['CID'], 10);
avatar
Уговорили. Выглядит сносно.
avatar
Идея имеет место быть. Как фронтер считаю подход очень логичным. Фронтеру просто нужно будет писать свои методы, где описывать что и каким-образом получить.

Из плюсов (с моейточки зрения фронтера):
Полная независимость фронтера от бэкера при разработке стандартного функционала с токи зрения сервера. Получаем конструктор.

И предложений, дописть утилитарный класс, аля сериализация объекта в JSON и обратно. Для быстрого формирования ajax-ответов
avatar
Главное формализировать взаимодействие если разделяем разработку фронтенда и бекенда между разными людьми, то лучше всего максимально сузить фронт их взамодействия, чтобы четко прослеживать их связи, а не выяснять потом, кто накосячил со списком новостей.
avatar
Отличная идея. Нужно будет завтра обсудить на работе с ребятами.

Оставить комментарий