Архитектура server-side приложения

[x-yuri]

Наблюдая за другими проектами, мне понравился способ, при котором страница, на которую пришел запрос, сама вытягивает нужные ей данные.

за какими именно проектами?

Исходя из этого требования, становится понятно, что первый и третий варианты не подходят - придется дублировать агрегацию данных
для шаблонов и AJAX-запросов. В первом варианте шаблон сам агрегирует нужные ему данные. Во втором этим занимается отдельное приложение. А кто будет это делать для AJAX? Не круто.

неочевидно, приведи пример

1. Шаблон напрямую обращается к источникам данных (базе, например).
2. Шаблон дергает некую ручку (приложение), которое обращается к данным, формирует их в нужном формате и возвращает.
3. Приложение (а не шаблон), получает нужные данные из источников и передаёт их одной пачкой в шаблон.

т.е. твой объединенный объединенный вариант - 3-ий вариант, который в зависимости от шаблона "получает нужные данные из источников и передаёт их одной пачкой в шаблон"? Так это чистый 3-ий вариант, получаемые данные определяются шаблоном в любом случае.

Эмм, это уже лишнее. Всё-таки окружения разные, значит и код должен быть разным.

почему нет? Я слышал такой аргумент в пользу nodejs, собственно вот

Если определение этих наборов переложить на контроллер - он будет сильно разрастаться. Поэтому я и разделил на несколько контроллеров и назвал их сервисы.

очень смутно представляю, что и как будет разрастаться...

я думал, ты на сервисы разбил в связи с ограничением количества одновременных запросов на домен. Ну т.е. по инерции, после статики (или они тоже отдельные сервисы?). Вообще создается впечатление, что роутер у тебя будет внешне-внутренним, в результате...

Если такая терминология подходит, предлагаю переходить на неё. Если нет - объясни какие моменты считаешь нелогичными/непонятными.

вы какую-то свою терминологию (а может и реализацию) придумываете, вас трудно понимать. Самый распространенный вариант - контоллеры и экшены. Экшены - действия, контроллеры - группы действий. И url часто имеет вид: /[controller[/action[/id]]], например /users/delete/1 или /users

Реализация у меня такова, кратко:
1. Шаблон, выступает в качестве client-side/virtual-client-side приложения, никак не связанного c View и ни с чем другим. Собственно он дергает ручки контролера.
2. Контролер, занимается перенаправлением требований от client-side и не более того, то-есть client-side дергает ручку контрола, контрол дергает нужную модель, на основе запроса.
3. модель, собственно занимается формированием данных, обработкой запросов и т.д. Формирует данные и отдает их уже выходному view.
4. View, собственно отвечает за то в каком виде отдать клиентской части данные, в формате JSON ( тоесть по запросу AJAX ) либо уже сформированное view представление.

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

подожди, ты сравниваешь веб- и десктопные приложения? B~Vladi тебя не об этом спрашивал. И меня этот вопрос тоже интересует (в чем отличие твоей реализации?), потому что я не вкурил её, реализацию...

DjDiablo, я все еще помню, что ты обещал помочь с тестированием разобраться :\

p.s. карма напомнила ситуацию в Зимбабве

[B~Vladi]

за какими именно проектами?

Раньше мне попадалось что-то подобное, но сейчас не вспомню конкретно. Сейчас - Яндекс.Маркет, например. Хотя там нельзя сказать, что данные запрашиваются из шаблона, но и не из контроллера или ещё чего-то.

В любом случае это именно тот подход: "страница, на которую пришел запрос, сама вытягивает нужные ей данные."

неочевидно, приведи пример

В первом примере для генерации страницы агрегированием будет заниматься шаблон. Для AJAX-запросов какой-нибудь сервис/контроллер/как хотите.
Во втором примере вроде бы всё очевидно: для страницы данные формируются в одну пачку, для AJAX-запроса придется писать свой сервис/контроллер/как хотите

Так это чистый 3-ий вариант, получаемые данные определяются шаблоном в любом случае.

Ну не совсем. В третьем варианте контроллер обращается к источникам, а в объединенном дергаются ручки.

очень смутно представляю, что и как будет разрастаться...

Реализация получения данных в контроллере будет разрастаться.

почему нет?

Возможно в каких-то частных случаях - да (либа там какая-нибудь), а так нет. То же XSL-преобразование. API везде разное ==> разный код.

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

Не не, всё на один хост/порт уходит с клиента. А статика да, на разные. Но она отдается nginx-ом, так что в контексте разговора нам не интересна.

роутер у тебя будет внешне-внутренним, в результате...

Ну наверно, не до конца понял это определение. Предлагаешь делать по аналогии с express?

И url часто имеет вид: /[controller[/action[/id]]], например /users/delete/1 или /users

Ну он таким и будет. Только контроллер определяется до входа в логику. Т.е. запрос приходит напрямую в контроллер, а уже все экшены он разруливает сам.



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

карма напомнила ситуацию в Зимбабве

Кстати, да, даешь инфляцию в интернетах!

[x-yuri]

Возможно в каких-то частных случаях - да (либа там какая-нибудь), а так нет. То же XSL-преобразование. API везде разное ==> разный код.

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

Ну наверно, не до конца понял это определение. Предлагаешь делать по аналогии с express?

я имел в виду, что может оказаться, что у тебя роутинг выполняется сначала с помощью nginx, а потом уже самим приложением, т.е. правила будут разбросаны по коду. Вообще все зависит от того, как это будет реализовано...

какие проблемы я вижу?

1) говрят, в процессе рендеринга шаблона, может выясниться, что другой блок надо перерендерить. Мне никаких конкретных примеров в голову не приходит.

Разве что несколько другой вариант, когда блок может потребовать подключить далее по тексту страницы нужные js-файлы или вставить нужный js-код (вариант, когда теги скрипт указаны перед </body>). Но это вроде решаемо.

Т.е. если обобщить: рендеринг блоков может влиять друг на друга, и должна быть возможность это как-то решать

2) как будут исключения/ошибки обрабатываться?

больше ничего не приходит в голову...

Теоретически, должно быть реализуемо и не сложно. Вопрос в том, в чем преимущества активного шаблона и когда его использовать. Возможно, для основного контента страницы больше подходит пассивный шаблон, а для дополнительных (меню, баннеры, и т.д.) - активный...

ну и не надо забывать, что есть POST (действие) и GET (вывод), т.е. не на каждый запрос надо рендерить шаблон.

[B~Vladi]

Но это вроде решаемо.

Ну у меня решаемо.

как будут исключения/ошибки обрабатываться?

На каком уровне?

Вопрос в том, в чем преимущества активного шаблона и когда его использовать.

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

Возможно, для основного контента страницы больше подходит пассивный шаблон, а для дополнительных (меню, баннеры, и т.д.) - активный...

Возможно. Остается найти такой шаблонизатор, который бы позволял рендерить шаблон в обоих режимах.

[x-yuri]

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

На каком уровне?

вот и я о том же. Произошла ошибка при подключении какого-то блока в шаблоне. Как и где обработать эту ошибку?

Ну и данные будут запрашиваться только те, что требуются в конкретной ситуации, ничего лишнего.

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

Возможно. Остается найти такой шаблонизатор, который бы позволял рендерить шаблон в обоих режимах.

php

[B~Vladi]

php

как же я мог забыть об этом шаблонизаторе...

Раз уж речь пошла о шаблонизаторах, стоит говорить на примере какого-то конкретного. Предлагаю TSN, так как он будет использоваться у меня. Ну и в контексте NodeJS.

если шаблон будет напрямую обращаться к параметрам запроса, не нравится мне такой вариант

Чем?

Произошла ошибка при подключении какого-то блока в шаблоне. Как и где обработать эту ошибку?

Ну в любом случае это баг, его надо править. Отловить в контроллере это можно, отдав страницу 500 ну и с записью в лог, отправкой e-mail, sms, что угодно
Я считаю надо делать так.

Класс-вид, соответствующий шаблону, вполне может выполнять активные функции шаблона.

В этом случае при поддержке придется править и код класса и шаблон. Тогда как можно править только шаблон.

[x-yuri]

Чем?

слишком много знать будет, шаблон

Ну в любом случае это баг, его надо править. Отловить в контроллере это можно, отдав страницу 500 ну и с записью в лог, отправкой e-mail, sms, что угодно

а как насчет обработки ошибки в пределах блока? Т.е. если произошла ошибка при отображении блока, это не привело к тому, что вся страница не отобразилась

Ну и данные будут запрашиваться только те, что требуются в конкретной ситуации, ничего лишнего.

кстати, откуда вообще берутся мысли про какие-то лишние данные в случае с пассивным шаблоном?

и расскажи подробнее, как происходит обработка запроса. А то я вот придумал ситуацию, но не знаю, возможно ли такое при твоем подходе: запускается рендеринг шаблона и когда дело доходит до основного контента выясняется, что 404 Not Found. Т.е. весь этот рендеринг выше был ненужным, чего хотелось бы избежать

В этом случае при поддержке придется править и код класса и шаблон. Тогда как можно править только шаблон.

ну вот ты сам чуть выше рассказывал, почему ты придумал сервисы... Я не очень вкурил идею с сервисами, но зато с шаблонами вроде бы все очевидно: шаблон определяет как рендерятся данные (пассивная составляющая) и как получаются данные (активная). Для первого больше подходит язык разметки, для второго - язык программирования. Да, если шаблон небольшой - неплохо было бы объединить все в одном файле. Но с другой стороны это может мешать наследованию (шаблонов).

[B~Vladi]

слишком много знать будет, шаблон

Как бы да, но проблем я тут почему-то не вижу. Можешь привести пример, где это вызвало бы проблемы/неудобства?

а как насчет обработки ошибки в пределах блока? Т.е. если произошла ошибка при отображении блока, это не привело к тому, что вся страница не отобразилась

Полностью согласен, блок не должен показываться, но я пока не знаю как это решить у меня. Но решать как-то надо. Будем думать.

откуда вообще берутся мысли про какие-то лишние данные в случае с пассивным шаблоном?

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

и расскажи подробнее, как происходит обработка запроса

На каком этапе(ах)?

А то я вот придумал ситуацию, но не знаю, возможно ли такое при твоем подходе: запускается рендеринг шаблона и когда дело доходит до основного контента выясняется, что 404 Not Found. Т.е. весь этот рендеринг выше был ненужным, чего хотелось бы избежать

Эта ситуация решена в примере: сначала рендерится основной контент. Если вдруг в этой части выясняется, что рендерить нечего - не рендерим. Основной шаблон, увидев что контента нет, выдаст содержимое страницы 404 из отдельного шаблона. При этом ничего лишнего отрендерено не будет.
Рядом можно посмотреть на примеры запросов данных, если интересно.

Для первого больше подходит язык разметки, для второго - язык программирования.

Согласен. У меня получится, что само получение данных инкапсулировано в коде, а из шаблона идет только вызов и обработка ответа. Получается всё на своих местах.

Но с другой стороны это может мешать наследованию (шаблонов).

Смотря как оно реализовано. Не могу представить такую ситуацию, может потому что у меня нет такого наследования, о котором ты говоришь.

[B~Vladi]

но я пока не знаю как это решить у меня. Но решать как-то надо. Будем думать.

Решено.

[x-yuri]

Как бы да, но проблем я тут почему-то не вижу. Можешь привести пример, где это вызвало бы проблемы/неудобства?

пример не могу. Просто на мой взгляд, ты переносишь слишком много обязанностей на шаблон, повышаешь связанность. С точки зрения unit-тестирования это скорее всего тоже неудобно.

Полностью согласен, блок не должен показываться, но я пока не знаю как это решить у меня. Но решать как-то надо. Будем думать.

Решено.

как?

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

можно пример?

На каком этапе(ах)?

ну например, приходит запрос. Он передается в сервис, а потом в экшн сервиса? Кто запускает рендеринг шаблона, сервис? Или экшен? Есть отличие между обработкой GET- и POST-запросов?

Рядом можно посмотреть на примеры запросов данных, если интересно.

вот я и говорю, что ты переносишь часть кода в язык разметки. Т.е. код записывается отчасти с помощью языка разметки. А язык разметки неудобен для написания кода. И это не то же самое, что в php. В php код может быть внутри разметки.

Согласен. У меня получится, что само получение данных инкапсулировано в коде, а из шаблона идет только вызов и обработка ответа. Получается всё на своих местах.

с некоторым перекосом в сторону активности шаблона

Смотря как оно реализовано. Не могу представить такую ситуацию, может потому что у меня нет такого наследования, о котором ты говоришь.

да, потому что у тебя наследование недекларативное. Декларативность - проще и надежнее (сложнее сделать ошибку), но менее гибка, если это необходимо...

кстати, есть все-таки две вещи, которых немного не хватает в mustache...