Они есть... спрашивай в пм если что-то определённое интересует

Maxmaxmахimus, не умничай, сначала пойми о чем речь - потом комментируй.

Ты вообще не по теме написал. Ты не понял сути вопроса. И аргументов я не увидел.

Спасибо тебе, за старания и потраченное время.
А теперь прочитай название темы ещё разок: "Архитектура server-side приложения". Зачем ты сюда клиента прикрутил - для меня загадка.

На будущее: я в курсе как реализовать общение клиента с сервером, как реализовать API, в каком формате гонять данные, какие события вызывать.

Не стоит мне расписывать очевидные вещи. И не пиши больше в этой теме - ты мне точно ничем здесь не поможешь. Спасибо за понимание.

B~Vladi,
всё, что могу посоветовать - напишите лучше на форумах по perl, php, etc. у нас целый отдел делает серверную часть, пишут на перле. это действительно сложный процесс =)

Да ничего сложного там нет.

Ну да, только не на php. Вообще нода интересует.

В том что вы описали можно узреть аналогию с популярными патернами
================================================== ============

1) Шаблон напрямую обращается к источникам данных (базе, например).
Я думал так уже не пишут, с этого начилось программирование для web,
хотя нет пишут, DLE-engine так работает))

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

Такое поведение характерно для паттерна MVC, так работает джумла.
кстатии привет от Smarty, он тоже очень любит дёргать за всякие ручки.

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

Подобное поведение характерно для паттерна MVP, так работает YII.

Конечно эти сравнения с натяжкой но всё же похоже.

DjDiablo, спасибо, с DLE и YII не работал, но в курсе.

Сейчас я остановился на третьем варианте, с учетом что мой шаблонизатор подразумевает на вход уже сформированные данные.

Я всё таки решил закончить мысль.
Я пока отлажу в сторону архитектуру, и сосредоточусь на ином вопросе.

Для начала, кто сказал что надо рендирить список мудаков и для клиента и для сервера. Помоему данное дублирование неразумно, это двойная работа при планировании, при разработке , при отладке, при доработке в следующих версиях.

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

1й) Рендерим json для клиента.
Это значит что на клиенте будет скрипт знающий какую ручку дёрнуть, скрипт будет регулярно запрашивать данные с сервера, соответственно на сервере будет контролёр который будет уметь эти данные отдавать.

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

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

2й) Рендерим html и для сервера, и для клиента.
в этом случае подразукмевается что данные на сервере превращаются в html а не JSON или XML.
Такой рендер удобен тем что он одинаков как для клиентской, так и для серверной части.
То есть, есть код который генерирует хтмл, который вы потом используете по усмотрению передавая его на клиент по ajax, либо вставляя шаблон.

Данный подход удобно реализуется паттерном HMVC.

Реализуем архитектурным паттерном HMVC.
Когда контролёр "A" вдруг обнаруживает что ему нужен результат работы контролёра "B", он просит контролёр "B" вернуть результат. Когда скрипт обновляет данные регулярно,то он обращается к контролёру "B" напрямую, get запросом. И вставляет HTML в нужное место.

Реализуем научив mvc вкладывать один view внутрь другого view.
Когда view "A" вдруг обнаруживает что ему внутри нужен отрендеренный "B", он рендерит B и вставляет его в себя. Когда клиентский скрипт нуждается в обновлении данных он запрашивает view "B" напрямую.

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

Ксать забавные тут идейки проскакивали - IP типовых Поисковиков не так уж и много
Вот почти весь перечень
Yandex,95.108.,77.88.,93.158.
Google,66.249.
Mail,94.100.,217.69.134.,217.69.136.
Rambler,81.19.
Yahoo!,67.195.,72.30.,74.6.,202.160.
Bing,207.46.,65.52.,65.55.,157.55.
Baidu,119.63.,123.125.,220.181.
Ask,66.235.
Ezooms,208.115.111.
Aport,194.67.

Ну дык вот - посколь как то делали многоаяксовый сайт, хотелось индексирование сохранить
Дык для поисковиков
Селектировали по IP и выделяли для них отдельный серв, цепляемый , как клиент/render к общему, который рендил и проксировал уже отренденное взятое от пользовательского серва для данных IP