Как создавать spa приложение на сервере?

Question

[vasIvas]

Вопрос не привязан к react или angular, он в абстрактном контексте бытия.
Как правильно создавать spa приложение на сервере? Понятно что хорошо, когда один экземпляр приложения запущен, это в духе и js и nodejs, типа модульность. Но вот контекст ноды, если специально не стараться, всегда работает с одним и тем же контекстом и тем самым заранее добавляет мыслей о том, что нужно специально создавать силой на каждое подключение индивидуальный инстенс. Это так? На каждое подключение нужно создавать отдельный экземпляр spa приложения для его пререндера?

Answer 1

[Сергей Протько]

It depends.

Изоморфность приложений, это весьма абстрактный термин который не подразумевает под собой никакой конкретики.

На каждое подключение нужно создавать отдельный экземпляр spa приложения для его пререндера?

Если UI не зависит от пользователя - можно вообще варнишом каким закэшировать это добро.

Если UI зависит от пользователя - опять же вопрос что нам нужно получить. Тот же реакт можно в рамках одного процесса рендрить совершенно по разному. Как и компоненты второго ангуляра. Но вот то как вы строите свое приложение уже может вносить раздор и т.д.

Изоморфность это круто но пока она мало у кого есть и люди еще не знают как правильно ее готовить. У каждого получается по разному.

Comments

[vasIvas]

Должно зависеть от юзера иначе было бы совсем просто. И это круто когда слышишь и думаешь, а вот когда делаешь то не все так однозначно. Просто мне кажется что было бы круто делать с одним экземпляром на сервере, но я не уверен что так получится. Мне очень-очень сложно представить приложение, которое вообще не хранит состояния в объектах. А ещё я не могу ответить на такой вопрос - если обработка данных у меня реализована функционально, то передав как глобальный стор одного юзера, приложение обработает его и не заменет на только-что вошедшего. То есть я в роутере на сервере получил пользователя, его данные и передал его в приложение. Но через долю секунды зайдет другой пользователь и я сного получу объект пользователя и передам его в приложение. Но приложение по сути, да и по факту, имеет только один инстенс и все его сервисы и прочие тоже имеют только один инстенс иначе бы они не смогли ужится с одним экземпляром самого приложения. и что? получается что с одним инстенсом приложения не получится?

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

[Сергей Протько]

vasIvas: вы когда-нибудь писали обычные web приложения? Ну те которые рендрят html, где на фронтэнде вообще нет JS и тд.? Мы можем там обойтись одним инстансом приложения?

Суть в разделении контекста. Если у нас все сервисы stateless, все UI компоненты stateless, то мы можем это добро реюзать из запроса в запрос, а то что имеет состояние (те же сторы) множить.

И да, универсального решения нет. У меня лично пока небыло необходимости в подобных вещах потому никакой конкретики сказать не смогу. А все что я видел и все о чем слышал - сугубо индивидуально. То что работает для одних не будет работать для других.

[vasIvas]

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

[vasIvas]

Сергей Протько: нет не делал я обычные :) Но меня это не сильно пугает, так как приблизительно я понимаю.. Но вот сейчас понял, что не понимаю, наверное, только сколько инстенсов приложения. Думаю что один и при заходе я получаю юзера из db, собираю все данные и передаю на рендер. Наверное все же одно... Да?

[Сергей Протько]

vasIvas: вы как-то извращаете понятие "функциональный подход". Суть "функционального подхода" заключается в имутабельности состояния.

Рекомендую посмотреть лекцию: Failure of state.

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

Что до этой штуки с "сложными структурами" и тд. - не вижу смысла в этом и предпосылок.

Ну и да, вот этот вопрос который у вас возник - это по сути "преждевременная оптимизация". Я не думаю что у вас проблемы с производительностью на сервере.

[Сергей Протько]

vasIvas: да, на сервере у нас все максимально упрощается. На сервер приходит запрос, мы запрашиваем все необходимые данные и как только они приходят, прокидываем их в компоненты. Мы ограничены запросом/ответом, в рамзках этого промежутка времени состояние поменяться не должно.

[vasIvas]

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

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

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

Это интересно. И спасибо за статью про angular2, она очень понятная и интересная.

И вот ещу что... Под функциональным программированием я понимаю подход, когда функция при передачи в неё одного и того же значения будут возвращать один и тот же результат. Типа -

function multy(a, b){
    return a * b;
}

function getFilmById(id){
    return Film.find(id);
}

Хотел ещё пример с каррированием добавить, но не смог придумать :)

[vasIvas]

Сергей Протько: Скажите, а в angular2 сохранился подход с инжектором? Типа app.service(name, ...])?
А то я пришел к выводу, что нужно написать такой же для реакта, но с небольшими изменениями..
Нужно сделать понятие scope для самого инжектора, чтобы та часть которая должна создаваться для каждого пользователя , так и создавалась. А вот те части которые просто обрабатывают данные, должны присоединятся к создаваемому.

[Сергей Протько]

vasIvas: в angular2 контейнер зависимостей это отдельный независимый компонент. Так что нет никаких проблем с использованием оного в react приложениях.

[vasIvas]

Сергей Протько: ого! А Вы подскажите где этот компонент найти? У меня не получается.

[vasIvas]

Если пролистать этот класс до конца https://github.com/angular/angular/blob/master/mod..., то можно подумать что в гугле порно актеры работают. Это даже нуб так бы не сделал.

[vasIvas]

Сергей Протько: мне нужно этот пакет взять и скомпилировать или есть просто отдельная библиотека?

[Сергей Протько]

vasIvas: вы о чем именно? О всех тех микрооптимизациях которые позволяют значительно ускорить сборку объектов?

Вообще в angular1 было примерно так же, но больше комментов о том почему были приняты те или иные решения.

на данный момент актуальный код только в основном репозитории, когда будет произведен сплит - без понятия. https://github.com/angular/di.js То есть можно попробовать использовать модуль из основного модуля... но.. проще взять любой другой контейнер зависимостей.

[vasIvas]

Сергей Протько: Вам не кажется что глупо говорить о микро оптимизациях, когда пропагандируешь функциональный подход, который, как Вы сказали, раньше не использовался из-за своей "тяжести".

А ещё более странно что они предлагают класс обертывать в функцию..

[vasIvas]

Сергей Протько: и я нашел di bottlejs называется, он как в первом angular, но немного не подходит. И я решил и его не использовать и свой пока не делать, так как день или два на него потратить придется.

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

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

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

И ещё было бы прикольно если бы добавть параметр private и public, для того чтобы модуль cookie скрывал свои фабрики ServerCookie и ClientCookie.

[Сергей Протько]

vasIvas: зависит от количества операций. Если у вас операция происходит сотню раз в секунду - то полный цикл flux-а это возможно не лучший подход.

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

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

ps. buttle.js вроде как делает именно это, ресолвит граф зависимостей.

[vasIvas]

Сергей Протько: а что значит "ресолвит граф зависимостей"? Про все методы я понимаю, а вот про resolve(data) и defer(func) нет. Вы можете объяснить для чего это?

[Сергей Протько]

vasIvas: это типа фабрика для ленивой подгрузки зависимостей.

[vasIvas]

Сергей Протько: спасибо. А Вы ещё не подскажите, Вам методы этого инжектора не говорят что можно разбить на модули а потом воедино собрать, как в angularjs?

[Сергей Протько]

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