Ну вы и не строите здесь MVC, а просто используете терминологию. Причем тут MVC вообще? Тут он никак не подходит. Если проводить аналогию, React-компоненты — это View+Controller (с точки зрения UI), а с точки зрения Redux-приложения — уже редьюсеры/mapPropsToState — это «контроллер» (но даже язык не поворачивается это так называть). Модель — ее тут вообще нет. Есть состояние, и есть контейнер состояния (Redux), реализующий Flux-паттерн. И зачем пытаться подогнать это под совершенно иной и не имеющий отношение к делу паттерн? Какие плюсы в назывании всего этого MVC?
Да, это верно — в Бэкбоне не было компонентного подхода в таком виде.
Собственно говоря, у каждого фреймворка в чем то своя идеология, но все современные движутся в общем направлении — Ember тоже отошел от View и Controller в пользу компонентов. Angular 2, React, Aurelia — все построены на них изначально.
А чем он на «контроллер» то похож? Обычно в архитектуре клиентского приложения контроллер — это что-то, отвечающее за подготовку данных для View в определенном контексте. Redux только хранит состояние и реализует структурированную смену состояния приложения (Flux), его можно вообще без View, React или чего бы то ни было использовать.
На мой взгляд, самое распространенное заблуждение по поводу React — это то, что его называют «V из MVC». Чаще всего, конечно, в сравнении с Angular — мол, Angular это полноценный MV*, а Реакт — только View и поэтому их сравнивать нельзя. Не совсем так, ибо React — это, по сути, View + Controller (в виде компонента), а в Angular все равно нет нормального «M» ($resource не считается, все равно его почти никто не использует). То, что Angular добавляет из коробки всяких сервисов, i18n, фильтры, и прочее — это, к MVC, в общем-то, отношения не имеет. А все остальное к обоим все равно лепится внешними модулями/пакетами.
А почему вы называете Redux «контроллером»? Он вполне однозначно определяется как «контейнер состояния» (сами рекламируют его как «predictable state container»). Причем тут контроллер?
Ну, неприменимость React в вашем данном случае — это отдельная история.
Но отдельно хотелось уточнить — чем вот именно Redux «не подходит»? Это же просто контейнер состояния клиента, который можно смело заполнить на сервере.
react-views просто использует React в качестве движка шаблонов на сервере (они и сами говорят, что он не имеет особого отношения к Реакту на клиенте). А так — node.js-сервер может рендерить Реакт-преложение (или отдельные компоненты — как угодно), а это да — полностью решает проблему серверного пре-рендеринга.
Ага, я тоже смотрю CHANGELOG, но как-то пропустил этот момент. В документации об этом прямо совсем вскользь крупица информации и дальше большой кусок про "Data Volume Containers".
А в чем получается практическое отличие named volume (с local-драйвером) от, собственно, от bind-mount папки хоста напрямую?
Сейчас это довольно прикольная штука, правда я лично жду import/export машин, сейчас это оочень неудобно и использовать можно разве что в рамках ci сервера например (для деплоймента).
А можно вот тут поподробнее? Что именно неудобно и каким боком Machine пересекается с CI?
Ну в документации Докера как раз написано про Data-Only Containers как один из вариантов. Я читал про --volume-driver, который позволяет использовать, например, Flocker. А что именно поменялось с 1.9 в этом плане? Реально интересно, ибо сам еще новичок в Docker (и DevOps вообще), и хотя активно отслеживаю эту тему — не всегда понятно, какой из доступных опций лучше воспользоваться.
Сам докер "ставится" с помощью docker-machine, но вы правы, Ansible очень даже нужен для всего этого дела, хочется же как-то одной командой все настраивать.
Логи, как уже отметили выше, обрабатываются с помощью специальных утилит, и stdout — самое оно. Тут я полностью придерживаюсь того, что предлагают 12factor в качестве подхода. Инфраструктура "сама решает" куда отправить логи.
Ну так вся суть Data Volume Container'а же в том, что данные храним именно в нем (главное, не удалять этот контейнер). Если мы используем папку на хосте, то какой тогда вообще смысл в отдельном контейнере для этого? Плюс, в случае папки на хосте, мы привязываем сервис работы с данными к определенному хосту Swarm-кластера и вынуждены настраивать этот хост особым образом.
Да. Но это лучше будет рассмотреть в отдельной статье про микросервисы. Докер, как платформа позволяет запускать несколько задач в контейнере, но лучше пересесть на микросервисы.
А аргументы Phusion в пользу использования baseimage-docker еще актуальны в последних версиях Docker? Вообще, целесообразно ли его использовать? В сообществе Docker, на первый взгляд, никто его не использует.
Данные не принято хранить в контейнерах. Они должны храниться за пределами контейнеров.
А в чем проблема использовать Data Volume Containers? Реально интересно, так как на этот счет какие-то полярные мнения в сообществе Docker'а.
P.S. Статью про микросервисы было бы очень интересно почитать
Легко потерять голову, если ты выпал из фронт-энда на 1-2 года.
1-2 года?! После такого можно смело возвращаться обратно в школу :) Достаточно выпасть на месяц — и приветос.
Ну на самом деле надо прямо мега-активно крутиться в теме фронтенда, отслеживать основные тренды и технологии, тогда более-менее все (почти) укладывается в голове. Но выбор слишком огромен — факт.
Да, как бы, у Мерседеса тоже изъянов полно. Как и у БМВ. Причем, у каждого свои. Тут вопрос, скорее, не чем он плох (пользователи и так это знают), а чем он хуже/лучше в сравнении с %browser%.
Концепции очень разумные. Сам долго плевался от синтаксиса и этих двойных подчеркиваний и всего такого, но в итоге сдался, потому что это чертовски удобно, вариантов используемого синтаксиса не так уж много (не любитель camelCase в CSS, поэтому остановился на BEM с синтаксисом Гарри Робертса, по примеру Гугла и Salesforce), а преимущества на дистанции — очень солидные.
Все равно многие вещи остаются не очень очевидными, конечно, это не решает всех проблем именования в CSS, со временем все равно накапливается технический долг в проектах по части CSS и часто присутствуют проблемы интеграции с готовыми решениями/фреймворками вроде TWBS, Foundation, Semantic, итд, но, думаю, всему свое время. Может и BEM предложит что-то еще.
Собственно говоря, у каждого фреймворка в чем то своя идеология, но все современные движутся в общем направлении — Ember тоже отошел от View и Controller в пользу компонентов. Angular 2, React, Aurelia — все построены на них изначально.
На мой взгляд, самое распространенное заблуждение по поводу React — это то, что его называют «V из MVC». Чаще всего, конечно, в сравнении с Angular — мол, Angular это полноценный MV*, а Реакт — только View и поэтому их сравнивать нельзя. Не совсем так, ибо React — это, по сути, View + Controller (в виде компонента), а в Angular все равно нет нормального «M» ($resource не считается, все равно его почти никто не использует). То, что Angular добавляет из коробки всяких сервисов, i18n, фильтры, и прочее — это, к MVC, в общем-то, отношения не имеет. А все остальное к обоим все равно лепится внешними модулями/пакетами.
Ну, это так, к слову :)
Но отдельно хотелось уточнить — чем вот именно Redux «не подходит»? Это же просто контейнер состояния клиента, который можно смело заполнить на сервере.
А в чем получается практическое отличие named volume (с local-драйвером) от, собственно, от bind-mount папки хоста напрямую?
А можно вот тут поподробнее? Что именно неудобно и каким боком Machine пересекается с CI?
--volume-driver, который позволяет использовать, например, Flocker. А что именно поменялось с 1.9 в этом плане? Реально интересно, ибо сам еще новичок в Docker (и DevOps вообще), и хотя активно отслеживаю эту тему — не всегда понятно, какой из доступных опций лучше воспользоваться.Логи, как уже отметили выше, обрабатываются с помощью специальных утилит, и stdout — самое оно. Тут я полностью придерживаюсь того, что предлагают 12factor в качестве подхода. Инфраструктура "сама решает" куда отправить логи.
А аргументы Phusion в пользу использования baseimage-docker еще актуальны в последних версиях Docker? Вообще, целесообразно ли его использовать? В сообществе Docker, на первый взгляд, никто его не использует.
А в чем проблема использовать Data Volume Containers? Реально интересно, так как на этот счет какие-то полярные мнения в сообществе Docker'а.
P.S. Статью про микросервисы было бы очень интересно почитать
1-2 года?! После такого можно смело возвращаться обратно в школу :) Достаточно выпасть на месяц — и приветос.
Ну на самом деле надо прямо мега-активно крутиться в теме фронтенда, отслеживать основные тренды и технологии, тогда более-менее все (почти) укладывается в голове. Но выбор слишком огромен — факт.
Так нельзя откинуть. Это же бизнес-единица, прежде всего, и нужно рассматривать именно с этой стороны.
Все равно многие вещи остаются не очень очевидными, конечно, это не решает всех проблем именования в CSS, со временем все равно накапливается технический долг в проектах по части CSS и часто присутствуют проблемы интеграции с готовыми решениями/фреймворками вроде TWBS, Foundation, Semantic, итд, но, думаю, всему свое время. Может и BEM предложит что-то еще.