Разделение backend и frontend. Или почему этого не будет в скором времени, хотя варианты есть

Напишу сразу, чтоб небыло вопросов в дальнейшем.

Для меня:
backend — серверная часть (работа с БД, обработка данных, и т.д.), вообщем все, чего клиент не видит.
frontend — все что видит клиент (верстка, JS скрипты, флеш и т.д.)

Очень часто я вижу сообщения с очередными «велосипедами» как разделить фронтенд часть от бекенд части (мухи отдельно, котлеты отдельно).

Не так давно в одной из статей на Хабре предлагали фронтенд делать XSLT файлами (аля как в Java), еще раньше все ударились в MVC архитектуру. Но мне это все не нравится и я сейчас объясню почему.

1. Мне _не_ нравится что вьюхи лежат в проекте (да, я плохой backend dev и редко хочу копаться в вьюхах).
2. Мне _не_ нравится что я преобразовываю корректные данные чтоб они «красиво легли в вьюху».
3. Мне _не_ нравится что вообще связан фронтенд и бекенд.

Вам тоже это не нравится? Тогда вам подкат.

Начало

Года 4 назад я впервые увидел MVC архитектуру и не мог нарадоваться. Как же хорошо что все было разбросано по разным папкам и теперь понятно куда и зачем смотреть.
Радость длилась недолго. Ровно до того момента пока я не попал на серьезный проект где было огромное количество вьюх и еще больше моделей, контролеров, либ и т.д.
Тогда я встретил кучу людей которые считали что контролелы должны быть очень маленькими. Модели — только работать с БД. А все что преобразовывает данные для вьюх — в либы. Удивился, но вроде они умнее и я начал писать как они. И мне это надоело.
Я начал искать аналоги MVC прекрастно понимая что это не silver bullet, и явно кто-то придумывал что-то еще. Скажу сразу, все что я нашел меня всеравно не устроило на 100%, но об этом ниже.

MVC? XSLT ?

Чем мне не понравился MVC:
1. Если у вас больше 1000 вьюх — вы застрелитесь их поддерживать.
2. Вьюхи лежат в проекте
3. С выходом новых и новых шаблонизаторов возникнет желание с ними «поиграться»
4. Любой рефакторинг в модели/контролере может привести к тому, что вьюха не получит каких-то данных.
5. Вам необходимо преобразовывать данные для вьюх и передавать их в вьюхи. В контролерах четко указывается какая вьюха где будет вызвана.

Да, XSLT немного более «жестко» позводяет держать под контролем ситуацию и не создавать код вида:

<ul>
       <? foreach($array as $item): ?>
       <li><?= $item->title ?></li>
       <? endforeach; ?>
</ul>

Я думаю Вы такое видели очень часто в своих вьюхах.

И тут возникает вопрос — «А что делать ?».

Ответ оказался не такой и сложный, благо его используют повсеместно уже лет 5, а может и больше — AJAX.

AJAX? Silver bullet ?

Сейчас начнете кидаться камнями и рассказывать о том что аякс это плохо (был у меня такой знакомый), или о том что я ничего не понимаю (и такой еще один был) но я закончу всетаки.

Нет, это не silver bullet и я объясню дальше почему, но для начала давайте просто посмотрим что нам дает отказ от MVC в строну аякс-приложения.

1. Вся фронтенд часть может спокойно лежать отдельно (другая репа, другой сервер, да что угодно).
2. Рефакторить все еще сложно (хотя есть решения с версионностью, если будет интересно я о них расскажу в следующих раз). Но если в методе в ***Doc блоке писать что мы передаем то рефакторить уже проще.

/**
* @return array(
'id' - int ID of item
'title' - string title of item
'link' - string link of item
)
*/
function test(){
// something
return $data;
}

3. Разделенный бекенд и фронтенд.
4. Возможность добавить еще варианты выдачи информации (ниже я покажу как).

JSON? XML? Да не проблема

На самом деле для AJAX все мы сейчас в 90% используем JSON. Это очень хорошо и им приятно пользоваться (спасибо создателям). Но например через год заказчик захочет сделать мобильное приложение (сейчас это далеко не редкость, с учетом что почти у каждого в кармане/на столе лежит смартфон). И мы начинаем писать много кода и вьюх чтоб выдавать XML для этого приложения (Я ж надеюсь Вы согласны с тем, что нужен именно XML который будем парсить SAX парсерами а не JSON ?).

Давайте рассмотрим как можно сделать простенький контролер который будет выдавать данные в любом формате

class Controller{
    /**

    */
    public function test(){
        /**
        Да, я не сторонник создавать объекты в методах и считаю что в 99% можно отлично использовать фабрику с Service Layer. Это мое мнение, извините.
        */
        $model = SL::get('Model');
        $data = $model->getData();
        $this->_view($data);
    }

    /**
    Собственно это и есть основная функция. Она и отдает контент в тех видах, которые нам нужны.
    */
    private function view($data){
        $format = $_SERVER["CONTENT_TYPE"];
        switch($format){
              case "XML":
                  SL::get('ViewRepresentation')->asXML($data);
                  break;
              case "JSONP":
                  SL::get('ViewRepresentation')->asJSONP($data);
                  break;
              default:
                   SL::get('ViewRepresentation')->asJSON($data);
                   break;
        }
    }
}

Как только у нас появятся еще 10/20/30/… и т.д. разных форматов добавить их будет не проблема.
Таким образом все данные на выходе это XML/JSONP/JSON. Никаких проблем при работе с ними быть не должно. И если завтра прийдет клиент и захочет SOAP — ну добавите еще один тип данных на выходе.

Проблемы

Да, как же без них.

Версионность

Вам нужна будет верисонность. Ёё можно придумать самому или почитать материалы о том, как создавать версионные API (возможно напишу об этом в следующей статье)

SEO

Да, я с каждый прожитым днем все больше не люблю этих специалистов… И дело не в том что они плохие ребята, наоборот они очень хорошие люди. Просто они часто стоят на пути прогресса. Они никогда не дадут ввести AJAX вместо готовых страниц. Не дадут по одной причине — поисковые гиганты не хотят платить деньги и писать JavaScript эмуляторы для своих пауков. И если ничего меняться не будет — мы так и будем сидеть с тем, чтоб отдавать паукам уже полностью готовые странички (ну да, паукам же легче жить с этим ...)

CMS/CMF

Никогда ниодна CMS/CMF система не перейдет на AJAX. Просто потому что это потребует переписать больше половины кода и еще огромное количество времени пересматривать архитектуру.

Итог

Как итог могу сказать одно. Варианты как разграничить frontend и backend есть. Многие фирмы их используют (ФБ, ВК передает JS скрипты, еще часть сайтов — JSONP, для мобильных клиентов делают отдельный вход с XML форматом). Но в массовость это врятли перейдет до того момента, пока к этому нас не подтолкнут поисковые гиганты. Ведь в сегодняшнем мире никому не нужен супер-пупер навороченый сайт который крутиться на 100500 странице поисковика. А жаль.

Updated

Почему нужно разграничивать frontend и backend ?

Сразу отвечу. Если например завтра вы увидите что 1 страница из ваших 8000 страниц стала отдаваться медленно и захотите переписать какойто блок этой страницы например на Java / C# / etc. то Вам не нужно будет разбираться с тем, как не поломать всю оставшуюся страницу. Она просто будет получать тотже JSON только уже с другого ЯП, что по моему мнению очень правильно.

Автор: Gron