Это делает фалькон )

это делает бэкэнд) любой.

а фронтэнд собирает

Какой фронтенд ?

который ты заджикверил и забутстрапил)

но нахера тут фалкон я всё ещё не понимаю)

Не, ты напиши конкретно какой язык че делает

Вот в фальконе логика понятна - приходит запрос, nginx его проксирует на phalcon, тот отрабатывает свою логику согласно разделу новости (acl и все такое), потом идет забирает из редиса 5 ключей и из них рендерит страницу. И отдает.

Это читаемо, логично, тестируемо, все привыкли. А в случае nginx<->redis как это выглядит?

а зачем он забирает всё это и генерит на сервере, если можно всю "статику" тупо доставать из того же редиса нжинксом?) без участия фалькона? пришёл запрос, проверил, часть сгенерил, часть нжинксом отдал - какой-нить тупорылый js всё склеил воедино

две основные проблемы программирование - именование переменных и инвалидация кеша ;)

инвалидация в данном случае не отличается никак) ключи известны, данные в них тоже)

есть вполне реальные случаи, когда кеш не работает

Ну вытаскивать логику на уровень JS, да, попахивает. Придется писать костыли для инвалидации всего этого дела.

есть вполне реальные случаи, когда кеш не работает

ну тогда он будет по старинке обращаться и получать данные. Приложение никак не меняется

но даже в твоей схеме фалкон на кой хер нужен-то? что бы сползать в мускуль?

5 лет назад так точно было, да и сейчас я был бы против того чтобы на фронтенде что-то такое сложное делать.

поздравляю, как только фалкон ползёт в мускуль он превращается в ничто)

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

но даже в твоей схеме фалкон на кой хер нужен-то? что бы сползать в мускуль?

В редис а не в мускуль

в редисе кеш) а данные где?)

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

в редисе кеш) а данные где?)

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

ну вот...

а сложная логика на nginx - это тот же интерпретатор опять, perl там или lua...

короче пустой холивар. Кто-то кого-то явно не понимает

взять фалькон, ползать в мускуль - победа. Всем рекомендую Рабочий вариант :)

в редисе.. не кеш, в редисе данные...

выше прочти)

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

ну из описания Павла я понял, что он именно этим и занимается: выплёвывает на страницу)

ну он очень условно.. мы тут все немного о сферическом коне в вакууме

да ещё и всякие лайки держит в представлении той же новости. ну такое себе решение) фалкон тут за яйца притянут и опять-таки нахер не нужен)

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

А таких рекомендаторов всегда были тонны, которые знают как лучше_всего_сделать и просто_и_лихо, а когда доходит до реальных проблем так все эти рекомендации терпят фиаско(

ну вот например, новостной сайт, когда ты ленту меняешь на ходу для посетителя в зависимости от просмотренного

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

ну вот например, новостной сайт, когда ты ленту меняешь на ходу для посетителя в зависимости от просмотренного

да меняй как угодно) когда ты отдаёшь контент частями это даже легче, чем собирать всё на сервере)

И надо гавнокодить на lua прямо в nginx мясо кровь кишки. Типизация потеряна, юнит тестами не покрыть. Так и живем.

ну не будешь же ты с клиента в ленту новости по одной запрашивать

не надо там ничего говнокодить, хоспаде)

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

опять же, что бы определить - какие новости запрашивать, нужно взять профиль клиента, посчитать что-то и решить - что отдавать

ну не будешь же ты с клиента в ленту новости по одной запрашивать

и? ну вот хоть убей проблемы не вижу :(

и? ну вот хоть убей проблемы не вижу :(

Ну лично я так и не вижу, где в твоем месте у тебя логика сборки размещена. Кто решает какие куски отдать на клиента?

Ну лично я так и не вижу, где в твоем месте у тебя логика сборки размещена. Кто решает какие куски отдать на клиента?

и сервер, и фронт

мы не о проблемах, мы о том, что есть случаи, когда собственно логики мало, i/o быстрый (память), и результат в кеш не положишь, ибо будут сплошные miss-ы

и тут важно снизить затраты приложения

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

не ну затраты приложения определённо снизятся, если страницу генерить на сервере

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

она ровным счётом ни чем не отличается от твоей привычной картины. я выше уже флоу расписал

Ну то есть фалькон)

если ты фейсбук - можешь написать свой компилятор ;) если помельче - можешь фалькон взять, пару кусков на зефире

https://ruhighload.com/nginx.ssi.jpg

даже с картинкой)))

кто определит - какие блоки отдавать клиенту то?

только приложение

да

оно же данные в кеш и положит

у тебя есть экшен getNewsFeed там в зависимости от каких-то параметров ты генеришь ответ

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

ты отрендерил ответ и параллельно закинул его в мемкеш.

какой тут кеш

фальконом.

ты думаешь фейсбук кеширует ленту?

уверен даже

;) нет

ну значит они молодцы) им денег хватает

Ладно я даже согласен с тобой когда сайт действительно тупо состоит из статически нагенеренных новостей. Но вообще то в реальных проектах такого уже нету лет 10.

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

Там например 80% статически нагенеренный новостей, а остальное - сплошной динамизм.

Ладно я даже согласен с тобой когда сайт действительно тупо состоит из статически нагенеренных новостей. Но вообще то в реальных проектах такого уже нету лет 10.

реальные проекты уже лет 10 на сервере не собираются)

реальные проекты уже лет 10 на сервере не собираются)

Ну это же лошь.

т.е. будет у тебя HIT в 1%... это не кеш, это деньги на ветер

ну возьми тот же фб, который Дмитрий привёл)

расскажи ему, что нужно собирать страницу целиком на сервере

Ну они могут даже не рендериться в html, но собирается страница все равно очень сильно бэкендом.

да схерали?

т.е. будет у тебя HIT в 1%... это не кеш, это деньги на ветер

ну с лентой скорее всего даже соглашусь

собрать json со списокм новостей - это в общем тоже "собрать сайт" ;)

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

зато это дешевле)

мне нет ;))

а так да...

ну у тебя есть http кеш, который часть инфы схоронит, которую они пожелают

Дешевле чем на бэкенде? А как же твиттор который отказался от client-side рендеринга ?

дешевле

поддерживать сложнее на самом деле

в разы

если ты не фейсбук, который свой реакт пилит

но для этого и придумали всякие штуки типа варниша

https://twitter.com/dan_abramov/status/924441145626816512

Это 2 месяца назад написано

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

фейсбук в качестве примера лучше подходит)

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

а фейсбук глючный как диэтиламид d-лизергиновой кислоты... особо в веб версии

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