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

[B~Vladi]

Мир кодерам.

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

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

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

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

Это самые частые механизмы генерации страниц, которые мне попадались.
Есть один важный момент, который мне нужно учесть: данные могут быть запрошены как для шаблона, так и в чистом виде. Например: на странице есть блок - ТОП10 мудаков сайта. Список мудаков нужно отдать в шаблон, при запросе содержащей её страницы. Затем, каждые 10 минут необходимо обновлять блок AJAX-ом, т.е. получить по-сути те же данные, которые отдаются в шаблон перед рендерингом.

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

Второй вариант подходит. Но. Что, если шаблон не умеет дергать ручки? Например, dust, TSN. Да, они могут вызывать функции, но результат при этом должен вернуться синхронно, а в NodeJS (мой проект на ноде) этого практически никогда не бывает.

Поэтому я ничего лучше не придумал, как объединить второй и третий вариант. Алгоритм:
1. Приходит GET-запрос на роутер (в моем случае это nginx). Роутер определяет сервис (раздел или подраздел сайта, к примеру), который обрабатывает этот запрос и проксирует ему.
2. Сервис, получив запрос, определяет какой шаблон с какими данными необходимо вернуть.
3. Дергает нужные ручки, в надежде получить от них данные в JSON.
4. После получения всех данных рендерит шаблон и возвращает результат.

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


Кто-нибудь имел дело с такой архитектурой?

Представьте, что вы устроились на работу в проект, где всё так устроено. Хотелось бы вам работать в таком окружении?

[B~Vladi]

UPD: Буду рад услышать ваши варианты, но с аргументами.

[Gozar]

Алгоритм:

Если приложение сложное, то я делаю именно так.

У меня не nginx решает, а php куда дальше передавать запрос или исполнение задачи. Запрос разбивается на части и определяется раздел и прочие данные.

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

[B~Vladi]

Немного поясню про nginx. Там, собственно, никакой магии нет:

	location /serviceName/ {
		proxy_pass http://127.0.0.1:8001;
		# Этот порт слушает сервис, т.е. HTTP Server NodeJS.
		# Каждый сервис на своем порту и не доступны извне.
		# Далее идут параметры кеширования.
	}

Другими словами: я разделил url на хост/сервис/параметры_сервиса. Выбрал nginx из соображений производительности. Причем соображения разные, например, попытаюсь запилить такую схему на AJAX-ответы:

Request -> Nginx -> Memcached -> Nginx -> Response.

Т.е. без участия backend-а (у nginx есть необходимый модуль). Ответ в бинарном виде (Для этого и писал Buffer.js).

[Gozar]

попытаюсь запилить такую схему на AJAX-ответы

Ну и нормально

[B~Vladi]

Больше никому нечего добавить? Хотя это не удивительно - здесь большинство клиентских кодеров. Но ведь должны же быть ещё знающие люди.

[Vantedur]

very complexity

[B~Vladi]

Vantedur, на картинке ничего не видно.

[Vantedur]

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

[B~Vladi]

И как это относится к теме поста?